オープンバンキング/API勉強会(2019-09-27)いってきたメモ

イベントページ

https://obie.peatix.com/

オープニング(MF瀧さん)

OBIのレポートを見ながら話す

  • MFの瀧俊雄取締役
  • レポートの立て付けから
    • 参考にはするべきだけどコピーして使えるものじゃないよね
    • イギリス 国有化したけどちっとも黒字にならない
    • LIBO操作の件とか(なつかしい)
    • イギリスの銀行の寡占状態
      • 日本と比較してだいぶん競争がないので手数料がすごく高い
    • もっと競争すべきだ、というバイアスが掛かっている点に注意!
  • MyDataの話
    • 取引がクリアだと健全だよね
    • 隣の家がいついくらで買われたかがわかる
  • PSD2の話
    • でたのは2016年、Activateされたのが2017とか2018
  • P.12、13あたりにこれらの施策がWorkしたのかが述べられている
    • レポートではMyDataは上手くいってない、と述べている
      • CSV公開しているだけだから、らしい
        • 毎回ダウンロードして、管理DBとかにアップして・・・・
        • 改ざん可能
      • 2014年ぐらいにODIもそういっている(?)
      • 2014年くらいの当初のAPI化は失敗した話
        • API使うために10画面くらい遷移するとか
        • UX足りなかったよね、という反省
        • OAuth的なもののガイダンスがでたのが2018年
        • P.23にグラフがある
        • MFでも当初60%ぐらい
          • 「合言葉」とかでてくるとすぐドロップw
  • OBIEってなんだ?
    • ちゃんと銀行が競争しているか
    • 公正取引委員会的なもの
    • メガバンク同士とか、メガバンクと新しい銀行がちゃんと競争しているか
    • レポートのタイトルがすごいw(2016年)
      • Making banks work harder for you
      • 銀行に向けた宿題が書いてある
      • CASS(普通預金乗り換えの仕組み)
        • (ケータイのMNPみたい)
      • ここから政治的意志を感じよう
    • では、日本には何が欠けているのか?
    • 資金を出しているのはCMA9(9大銀行)
      • かなり強烈な意識。日本ではできないだろうなー
    • ちゃんと使えるAPIを出しているか、使われているのかをチェックする人達がいる
      • 日本にこれはいない!
  • CMS OrderとPSD2との違いと共通点の図解
  • 結果としてどんなプレイヤーが生まれたか?もレポート
    • Open Banking Standardの成果は
      • ちゃんと更新もされている
    • 日本でも***が標準作ったが、送金には触れてなかったり、ざっくりしていて実際は方言があったりしている
      • それにそって実装している訳ではない
      • とはいえ、ベンダーの数ぐらいしかパターンがないので、がんばればいける(さすがMFさん)
  • そしてOpen Financeへ
    • 住宅ローン、保険、年金商品
    • 日本でも住宅ローンとか投信はとれないとかある
      • MFでも投信の日々の値動きで一喜一憂したいひとが結構いる(笑い
      • 投資信託は口座じゃないからスクレイピングしていい、とか来年でてくる?らしい
        • 金融庁はそこは触れていないからとかなんとか
    • まだ日本でも文献がない
    • 普通預金だとあまり考えないが(どうせ金利ゼロだし)、住宅ローンとかになってくると気になるオファーが出せるかもしれない
  • そしてPremium API
    • ここだけ読んでもいいよ!
    • これまでのAPIは"all stick and no carrot!"
      • 銀行に競争だけ生まれてメリットがない
    • お金の取れるAPIとして1つだけ事例を出していて、KYC。
      • たとえば与信額とか出したらどうか?
      • とはいえセクシーさがキツイ状態
    • 人がいままでしなかったことに価値がある、そこに収益分配の仕組みとしてPremiumAPIを
    • ちゃんとWin-Winのしくみになるように
    • KYC、本人確認もいい
  • まとめ
    • これまでの制度のなかで、失敗したことは失敗したとして見直しているところがすごい
  • QA
    • OBIEの経済効果は?
      • まだそこまでになってない、収益がでてない、これから
      • 基幹系に突っ込んでるお金と同じだよね、という議論も
    • CASSは霞が関どうみてる?
      • まぁ日本では強大な権限によって潰されるでしょうね(笑い
      • 自然発生的にでるかもしれない
      • 遺言とかそっちのがいいんじゃないかな
    • APIになってMFで、ドロップ率あがったとかあります?銀行の画面がイケてないとかそういうのがある
      • あんまり聞いてない。かわらないんじゃ?
    • EUでは難民の口座開設はどうなっている?本人確認とか。
      • 確率論でみているんでは。取引額が小さければザルとか
      • ちょっと高度でお答えできない
    • 課金の話は解決しない。当局が~
      • 当局は関係ないんじゃない?
      • 日経電子版で本日でたAPIの総覧で、データポータビリティが解決するね的なコメントした
      • 電代業はパシリですよ!お金取ってきて親玉がそれを全部取ったら、そりゃないよ!エンドユーザーに課金するの?おかしいよね!
    • CASSが日本に来るのにどれくらいかかる?
      • こないんじゃない?パシリがいればできるし
      • イギリスしかやってないし
      • raisinというのはある https://www.raisin.com/
      • 資金移動APIとeKYCが軽くなった世界では、実質CASSできるよね

Authlete工藤さん

  • 英国オープンバンキング技術仕様の概要
  • API Onboardingにも仕様・ガイドラインを定めている
    • Dynamic Client Registration
    • Open Banking Directory
  • FAPIとCIBAの上に、Read/Write DataのAPIがのっている
  • FAPIの話
    • セキュアなOAuth Dance
      • お配りした謎の板www
    • 登場人物は多いので、いろいろな視点で議論している
      • OpenID作ったひと、銀行、Authleteなどのベンダ
    • Fintech事業者と金融機関はMutual-TLS
      • A銀行さん固有の暗号アルゴリズムで~というオレオレ実装ではない
  • CIBAについて
    • 「CIBA見たことある人?あ、半分ぐらいいますね。じゃ話さなくっていいですかね?」笑い
    • CIBAじゃないやつ=Redirect Flow
    • Decoupled Flow
  • R/W Data APIの話
    • API設計でよくやる話がベースとしてまとまってる仕様
    • 特にsecurity & Access Controlがいい感じ
    • 例えばOAuthでいうScopeで「この取引だけ」にするには?
    • Intentで解決!
      • (QR決済もこれやっている気がする)
        • ワンタイムQR的な。もっと細かいのかなIntentは。
        • 取引内容を送って、それに対するIntentIDが帰ってくる、だった。
          • 「201 Createdで返ってくるのにグッと来るんですけど」w
    • この”Intent”の標準化
      • これがないと、顧客体験がバラバラに
      • Monzoというチャレンジャーバンクはマジックリンクでログインできるらしい「えっ銀行でそれやるの?」w
    • Customer Experience Guideline
    • OpenBankingのカスタマージャーニー=TPPとASPSPの連携
      • 原則を定めている
      • 例)Browser based redirection - PIS
      • こういう表示をしてくださいね、というガイドを定めている!!
      • 例)App based redirection
  • OB DirectoryとDynamic Client Registrationのはなし
    • OB Directoryの概念図。個々にやるとメッシュ構成になるので・・・・
      • (これ、日本にはないのか??)
    • TPPの登録を手でやるのではなく、自動でやる
  • 実装について
    • めんどうくさいところはAuthleteにやらせましょう!(笑い
    • FAPI認定、CIBA認定プログラムを取っている製品を使いましょう
  • まとめ
  • QA
    • FAPIでPublic Clientはなくなってるの?
      • ないよ(的な回答)
      • CIBAはその使用上、Confidential Client
    • FAQ.FAPIのヘッダは何を入れるの?リクエストボディに入れないのはなんで?

Appendix

sli.doの質問アーカイブ

Taka
3:58 PM

0
FYI: x-fapi- で始まる HTTP ヘッダーは、FAPI Part 1 の 6.2.1, 6.2.2 で言及されてますね。6.2.1 clause 12 では、保護リソースエンドポイント(いわゆる API)は、x-fapi-interaction-id をログに書かなければならない、と言っています。
Anonymous
2:23 PM

4
METIのデータポータビリティ検討(2018年) https://www.kantei.go.jp/jp/singi/it2/detakatuyo_wg/dai1/siryou4-2.pdf p.15みると、CASSの話は、将来的に予定しているようにも見えるが、このあたり霞ヶ関はあまり最近は意識していないのでしょうか?
Anonymous
2:21 PM

2
マネフォの話を伺いたいんですが、昔のインバンのID/パスをマネフォアプリで聞く方式からOAuthで銀行サイトに飛ぶようになった時に、登録完了率って落ちましたか? (銀行サイトだと画面のイケてなさとかあると思うんですが)
Anonymous
2:48 PM

2
API課金の問題は一向に解決しなさそうです。 当局と話している限りだと、どういった方向性に進むのでしょうか?
Anonymous
3:09 PM

2
マネフォ的には、各金融期間の独自OAuthを押し付けられて大変?そんなでもない?
Anonymous
3:16 PM

2
public client向けのFAPI対応がCIBAになりつつあるということでしょうか?(FAPI pt2ではあまりpublic clientの記載が明確に書かれていないようにみえます)
瀧
3:31 PM

2
工藤さんの資料 https://www.slideshare.net/tkudo/uk-open-banking-tech-overview-176632925
T
Taka
3:33 PM

2
CIBA 仕様で定義されているバックチャネル認証エンドポイントにアクセスできるのは confidential client だけなんですよね。そのため、仕様上、public client は CIBA を利用できません。 > Anonymous
K
Ken5
2:27 PM

1
EUにくる難民はオープンバンクのユーザーとしてカウントされてますか?その場合、彼らの口座開設時の本人確認はどのようにされてるのでしょう
Anonymous
2:48 PM

1
日本でCASSと同じことやると、メガ→ネットバンクへの口座流出が進みそうですね笑
Anonymous
9:39 AM

0
レポート本文はこちら https://www.openbanking.org.uk/wp-content/uploads/open-banking-report-150719.pdf
Anonymous
9:52 AM

0
2014年のHMTレポートはこちら https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/382273/141202_API_Report_FINAL.PDF
Anonymous
9:53 AM

0
AISP/PISP の一覧はこちら https://www.openbanking.org.uk/customers/regulated-providers/
Anonymous
10:44 AM

0
CMAのレポート(の解説ブログ)はこちら https://moneyforward.com/mf_blog/20160812/cma/
Anonymous
10:52 AM

0
OBIEのカスタマーエクスペリエンスガイドライン https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines.pdf
Anonymous
2:52 PM

0
CASSについて、権力に潰される、とありましたが、CASSが現実的に日本で検討会のソジョウに乗るのは、どのくらいかかりますかね。そこの部分、どういう状態になったら、FSAや公取は動き始めますかね。銀行への公的資金注入やらFintech企業のサービスが市民権をしたときでしょうか。
Anonymous
2:58 PM

0
電代業者に起因する問題が起きた場合、規制がより厳しくなることはございますでしょうか?
Anonymous
3:37 PM

0
マネフォ的には日本のすでにオープンAPIを公開している各金融機関の認証認可プロセスは同じようなUXになってると感じますか?
Anonymous
3:43 PM

0
Fapiのヘッダーって基本的にどのような用途で使われますか?また、なんで、ポストデータ内に含めないかいいつも気になってます
K
Ken5
3:48 PM

0
今マネフォが欲しいなのは、OAuthなどより銀行側がチェックリストでチェックしたい項目がすでに記載されてるdirectoryだと思うんですよね
Anonymous
3:59 PM

0
FAPI Part 1, 6.2.1. Protected resources provisions https://openid.net/specs/openid-financial-api-part-1-ID2.html#protected-resources-provisions
Anonymous
4:03 PM

0
intent内容を代行が表示して、銀行はあんま出さないというUX標準化って、 intent内容と表示を変えることが代行業は(機能的には)可能だと思っていて、銀行としては本当は代行業を全面的に信頼してはいけないとおもうのですが、 そのあたりの信頼関係ってどうなるんでしょうね? (いつかTwittertかでw)

2019-06-03 「Google Cloud で実践する Web アプリ開発」行ってきたメモ

おしながき

https://developers-jp.googleblog.com/2019/05/google-cloud-web.html

17:30 受付開始
18:00 ~ 18:05 オープニング
18:05 ~ 18:35 Web フロントエンド開発最新動向
        グーグル合同会社 宇都宮 佑亮
18:35 ~ 19:05 GCP のサーバーレスサービス紹介
        グーグル・クラウド・ジャパン合同会社 篠原 一徳 
19:05 ~ 19:20 休憩 
19:20 ~ 19:50  リクルートにおけるWebパフォーマンス改善の取り組み
株式会社リクルートテクノロジーズ 新井 智士 氏
19:50 ~ 20:20 インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発
株式会社Ginco 西川 達哉 氏
20:20 ~ 20:30 クロージング17:30 受付開始
18:00 ~ 18:05 オープニング
18:05 ~ 18:35 Web フロントエンド開発最新動向
        グーグル合同会社 宇都宮 佑亮
18:35 ~ 19:05 GCP のサーバーレスサービス紹介
        グーグル・クラウド・ジャパン合同会社 篠原 一徳 
19:05 ~ 19:20 休憩 
19:20 ~ 19:50  リクルートにおけるWebパフォーマンス改善の取り組み
株式会社リクルートテクノロジーズ 新井 智士 氏
19:50 ~ 20:20 インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発
株式会社Ginco 西川 達哉 氏
20:20 ~ 20:30 クロージング
20:30 ~ 21:30 懇親会

オープニング

  • ちょっと遅れる
  • 今回は実験的な取り組み
    • とくにフロントエンドとバックエンドの両方を同日にやったこととか
  • 「無音シャッターカメラを」というアナウンス。素晴らしい。
  • 厳し目に締めたけど満席!とのこと。

18:05 ~ 18:35 Web フロントエンド開発最新動向 グーグル合同会社 宇都宮 佑亮 さん

  • AMPとかそのあたり
    • スライドタイトル読み上げ、めっちゃ発音いいw
  • FirefoxPhoneが自販機$7で買える!?
  • FCP6秒、TTI9秒が中央値
    • なるほどこれは結構世の中がひどい
  • Preload,DNS Prefech,・・・
  • 1stStep 画像はCDN使おう
  • でも半年後にリグレッション
  • そこでPerformance Budget
    • HTMLやスクリプトのサイズに制限を設ける
      • ここまではやっていいよ、の基準
    • SRE的な発想かな?
  • Chrome UX Report!
  • Google Search Report
  • Lighthouse!LightWallet!
  • 事例)proxx.app
    • Chromeエンジニアが開発、廉価な端末でも高速!
      • 3G回線でも快適
    • ワーカースレッドを活用している
  • Portals機能を使ったトランジションとなりのヤングジャンプはてな
  • PWAの話
    • Trusted Web Activities
    • PWAをAndroidアプリに埋め込む
    • Desktop PWA
      • huluの例
  • WebAuthnの話
    • Yahoo!JAPANの事例
      • もう採用していたっけ?さすがだ
  • ShapeDetectionAPIを組み込む事例
    • FaceDetectorやBarcodeDetector
    • Web Percepton Toolkitとして公開中!
  • web.dev
    • ベストプラクティスを紹介してます!

AMPの話!

  • 4月にAMP Conf Tokyo開催
    • Yahooトラベルの事例
  • WebPackaging:AMP PackagerまたはCloudflareで
  • AMPでカスタムJS載せられるようにするよ!
    • より複雑なUXを提供できるよ
    • トライアル受付中
  • Accelerated Mobile Pages、の略称だったが、”AMP”になるそうです
  • 今後:GoogleSearchとのインテグレーション
  • 今後:AMP for e-Mail
  • YoutubeのAMPチャンネル見てね!

18:35 ~ 19:05 GCP のサーバーレスサービス紹介 グーグル・クラウド・ジャパン合同会社 篠原 一徳 さん

  • 打って変わってバックエンドの話
    • スライドも一気に親近感湧く感じにはw
  • Kazuuさん。社員証もKazuuらしい。
  • サーバレスって
    • no infra management
    • managed security
    • pay as you go
  • GCPのサーバレスはフルスタック!!
    • 考えること
      • どこでうごかす?(コンピュート
      • データベース
      • 非同期処理
      • 静的コンテンツ
      • コード管理、ビルド、デプロイ
      • モニタリング・ロギング・APM
    • 今日は上から4つを
      • 下2つも聞きたいなぁ

コンピュート

  • Functions,Apps,Containers
  • 使い分けチャートあるよ!見てね!
  • Functions
    • イベントドリブン
    • ランタイム制約あり
  • AppEngine
    • 対抗はHeroku、Elastic Beanstalk
    • こちらもランタイム制約あり
    • Firestore、CloudMemoryStore、Cloud Tasksを組み合わせてFront/BackのAppEngineを連携させよう
    • デプロイメントオプションあるよ!
      • B/G,Canary,A/B
    • 裏はDockerなのでDocker制約はある(らしい)
  • CloudRun
    • Knativeベース
    • CloudRunとCloudRun on GKE
      • 現状、無印CloudRunは1vCPU,mem2GBという制約あり
    • スマート水道メーターさんの事例をユースケースとして紹介
      • WebAppというかIoT
      • このときはCloudRunがCloudSQLに接続できなかったのでGAE使った(今はできる)
    • コンテナが必須、デプロイの検討が必要なところが考慮ポイント

ストレージ

  • Firestore
  • CloudSQL
  • Spanner
    • 水平スケールできる
      • CAP定理を超える謎の技術
    • 既存DBとの整合性、リージョン間レプリケーションの提供エリアは注意

非同期処理

  • Cloud Tasks
    • Pub/Subとの違い
      • スケジュール実行もできる!
      • レート制御もできる!
      • タスクの再試行ができる!
      • HTTP/S Auth(IAM)ターゲット!

静的コンテンツ

  • CloudStrage、デフォルトで3600Secのキャッシュ利いてるよ!

19:20 ~ 19:50  リクルートにおけるWebパフォーマンス改善の取り組み 株式会社リクルートテクノロジーズ 新井 智士 さん

  • 本日はリクルートの取り組みとSUUMOの取り組みの紹介
  • 性能改善の取り組み!
  • SUUMOは2009年からあるサービス、多くの機能追加
    • 過去Webパフォーマンス改善はやってきているが・・・
    • 改善がゴールになっている案件・・・
    • 属人化
    • なかなか定着しない!!!
  • これまでのWebパフォーマンスは「秒間どれくらい返せるか」とか
  • 今はコンテンツもリッチ、端末スペックや回線もバラバラ
    • サーバのレスポンス性能だけでは不十分!
    • HttpArchives.orgを見てみよう!
    • 感覚的にも8割9割はフロントエンドがボトルネックになってきてる
  • 多くの人に使ってもらうサービスとして、コントロールすべきもの!!

SUUMOでの取り組み

  • パフォーマンスバジェットと性能改善ハッカソン
  • 改善、維持、予防の順番で

性能改善ハッカソン

  • まずLighthouseで計測
  • 1日で一気にやる
    • ここでもweb.dev
    • web.dev/fast
  • ポイントは
    • とにかくLighthouseの点数を上げる!
    • 範囲を狭める(数ページで)
    • 現場の開発の人も巻き込む
  • 効果として
    • サービスに関する前提知識がほぼ不要なので、業務知識が少ないメンバーも貢献できる!
    • 普段触れないところに触れられる
    • 性能への意識改善(現場を巻き込んだ効果)
  • 代表的な劣化項目
    • 読み込む必要のない画面外項目
    • 表示サイズのアンマッチ(でかい画像なのに表示はサムネイルぐらいとか)
    • 古いCSS
    • などなど
  • 「パフォーマンスバジェットのご紹介」読もう
    • まずはレポーティングに使っている
    • 機能追加するときにその分なにを削る?みたいなツールにもなる
  • パフォーマンス計測ツール

19:50 ~ 20:20 インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発 株式会社Ginco 西川 達哉 さん

モバイルアプリの技術選定

  • フロント2名、バック2名
  • 開発スケジュールは5ヶ月!!!
  • GKEとFirebaseを選択
  • BCのバックエンドで大事なこと
    • 可用性、バージョンアップのしやすさ、作って壊してをやりやすい
    • そこでGKE
      • Stackdriverでロギングモニタリング自動!
    • 送金用と履歴用のノードを分けると24ノード!
    • それがさらにDev,Staging,Prodと3環境!
  • ブロックエクスプローラ、フロントエンドで大事なこと
    • BCノードは高負荷に耐えられない
    • 可用性、バージョンアップのしやすさ、作って壊してをやりやすい
      • 同じ!
      • BCのAPIによらない柔軟な実装をしたい
    • 最初はGAE+CloudDatastoreでやってた
    • Firestoreを直で(!?)
  • Firestoreの話
    • アクセスキーでアクセスできちゃうので・・・・の話
      • 以下はTwitterより
        • Firestoreの闇
        • FirebaseはValidation書くのがわかりやすくていい
  • その他イベントドリブン
    • 更新されたらPush通知とか
    • クラッシュログをGithubのIssueとSlack通知(!?)
      • Issueすごいことになりそうだけどな・・・
    • 行動履歴とか
    • 強制アップデートとか
      • RemoteConfig
    • Stackdriver
      • GKEとCloudFunctionsは自動
        • いいなぁ
      • Alert設定、Error Reporting

まとめ

  • Firebaseはクライアントエンジニア主体の開発体制にできるのがいい!

JAWS Days 2019メモ

AWS IoTのベストプラクティス」それホント? 10:10~

  • ソニー森本さん、AWS園田さん

  • 事例:マルチファンクションライト

    • スピーカーもついてる、家電の操作もできる
  • 1 デバイス証明書の管理

    • どうやって個別の鍵をセキュアに埋め込むか?
    • あとで配信する場合は?FOTAはできるけど
    • ファームウェア配信からのCSR送信で解決
      • 秘密鍵が外に出ないのがポイント!
      • でもなりすましとかいろんな対策はしている
    • 正攻法は工場で組み込む(セキュアな場所に格納できるので)、だけど。。
    • DeviceBootstrapパターン
      • 証明書が漏れたときのリスクも分析しておく!!
        • 個別にAWS IoT側でBANできる
        • Device Defenderで複数のクライアントIDが同じ証明書を使っていることは検知できる!
  • 2 WebAPIも使いたいんだけど

    • AWS IoTの経路を使えばいいが・・・
    • データ分析基盤に送るとかはやっぱりWebAPIへ投げたい
    • 双方向でやる必要がないログとか、まとめて送りたいとかはWebAPIがいい!
    • APIの認証を作り込む必要あり。
    • ただ、MQTTSを使ったほうがTLSハンドシェイクを抑えられて省電力
  • 余談:AWS IoTのお値段が高い!(高かった)話

    • 2018年にいきなり安くなったそうですw
      • メッセージサイズが512Byteから5KBに!(値段で言えば10分の1)
      • 使ったコンポーネントごとに課金、で安くなった
      • メッセージブローカを経由しないメッセージは更に安く(クラウドに上げさえすれば良いデータ)
  • 3 IoT CoreのLogging

    • AWSIoTLogsV2
      • JSONログになった!
      • Logs Insightと相性がいい
        • クエリ速度速いけどパケ死に注意!
        • なぜ速いかは「企業努力」www
  • 4 大量のメッセージ送信

    • 緊急地震速報みたいなユースケース
    • コネクションあたりの秒間Publish数の上限緩和はできない
    • アカウント単位の秒間Publish数は相談可能とのこと
    • なので、Topicを分けるのがプラクティス
    • 送りっぱなしでACKは返さない、送ったあとAPI叩くとかすると受け側が死ぬので注意!
  • 5 コネクションの切断検知

    • シーリングライトの壁スイッチ問題
      • スイッチオフすると主電源が落ちる
    • LWTをサポートしているのでこれを拾ってステータスをレポートする!
      • Alexaではこの対応ができてないとスキルの審査が通らないよ
      • ただリアルタイムではないので・・・
  • 6 Shadowの使い方

    • オフライン時にデバイスへのメッセージ送信が不要なので、Desired使わずにシンプルにできる
    • エラーを返すべきケースとか、1つのコマンドで複数デバイスが動く、などはShadowでなく
    • MQTTのPub/Subがいいシナリオ

SAに相談するのがいいよ!で締め。IoTはアップデートも速いので。

RDSリファクタリングと異種間DB移行の戦い - Amazon DMSを使った止めずにリファクタリングする手法

  • オミカレ 曽根壮大さん
  • 満席!人気セッション!
  • 資料はそーだいさんのブログで既に公開されているとのこと

    • すでに見たやつかも
  • 婚活サービス、8年もの、これのDBリファクタリング

  • 趣のある謎のデータww
  • 非正規化してパフォーマンスあがるのはSelectだけ。コードは複雑化するはUpdateは遅くなるわ。

  • Refactoring Database 英語の本はまだある、日本語はピアソンショックで絶版、プレミアついてる

  • Aurora使うとOSSではないので最悪心中のリスクがあるのでRDS for - PostgreSQLを採用
    • Postgreチョットデキルのでw
  • 商用は高いし(GoledenGateとかな)、OSSは運用コスト高い(作った人しかわからん)しサポート少ないし、でDMS

実際のところ

  • DMSのレプリケーションは数秒は普通に遅延する
  • かっちりやりたいトランザクションとかは厳しい
  • そこをAPI
  • APIのいいところはテストが書ける!
  • カナリヤリリースできる、ロールバックしやすい
    • 安心感が違う
    • 既存がでかすぎてロジックがよくわからないときにも
  • DMSは一時的な利用を想定したものなので、常時上げておくといろいろ不都合があるお話
    • リードレプリカの昇格はMackerelで検知してDMSのCFnを書き換えるようなタスクを書いたとか
  • RDSのログを監視しよう

    • 当時、RDS for PostgreSQLはCloudWatch Logsに対応してなかったそう
    • Aurora(Postgre互換)は今もない模様
    • なので、MackerelプラグインPHPで書いたっぽいお話
  • MySQLのZero Dateへの止めどない怒りw

  • UTCで揃えておいたほうがいい話

DBのせいでアプリコードがおかしくなってきたら、覚悟を決めてDBをリファクタリング

  • Q:ZeroDateどういれた?
    • A:マイナスインフィニティ、1年1月1日、UnixTime初期値などが考えられる
    • ORマッパーの対応、誕生日とかのからみで1年1月1日に。

ランチセッション3つ

気になるやつがそろったところをまとめて聞く

  • Spotinst 日商エレクトロニクス宮野さん
    • Spotinstすごく気になる
  • Teraform TIS横井さん
    • 解約時のリソース削除は手動でやりたくない、たしかに。
  • セキュリティテストの自動化 シノプシス伊藤さん

至高の CI/CD パイプラインを実現する5つの約束

  • ポジティブな Toriさん 小西 宏樹さん

  • 立ち見も満席の人気セッション!

    • 飛べない鳥さんw
    • 事前に録画した動画を流す形式
  • つい手動でやりがちな作業を断固として拒否する強い気持ちが重要

  • ビジネス層への理解を得ること、そのために必要なメトリクスをとって見えるようにしておこう

AWS Transit Gateway を使った新しいセキュリティ手法を試してみた

  • F5 伊藤 悠紀夫さん 39歳前厄

  • 便利になる一方で全てがつながるとセキュリティに問題あり

  • Reference Architectureも発表されている
  • セキュリティ用のVPCを用意する
    • そこにF5製品で実装したよというお話(したよというか紹介)
  • F5 Big-IpのWAF機能
    • ログはAWS Security Hubに対応しているので、Hubで集中管理できる
  • AWS WAFのマネージドルールにF5のエンジンがあるよ
    • 本日イチオシはボット対策ルール
    • POSTのペイロードまでは見れないが
  • OutboundのURLフィルタルールもF5で

    • Squidを自前で立てると大変(性能面とか、フィルタの柔軟性)
  • お客様事例:PIEM様 ブライダル業務効率化アプリ

    • 機微情報を扱うので情報漏えいは絶対にできない
  • お客様事例:某B2C検索サイト  - DDoSやBot攻撃でランニングコストを増加させない

AWSセキュリティ入門】徒然なるままに責任共有モデルの下から上までそこはかとなく解説

  • 大竹 孝昌さん

  • 早めに終わったので最後の10分ぐらいを聞く

  • 資料いい感じだった・・・社内に見せたい
  • 「これはセキュリティの基本なので。左手は添えるだけ。」

PenTesterが知っている危ないAWS環境の共通点 ~攻撃者視点よりお届けする狙われやすいAWSの穴~

  • 洲崎 俊さん、一ノ瀬 太樹さん、北原 憲さん

  • 狙うならやっぱりクレデンシャル!

  • キーは特に注意、の件。ローカルでも安全ではない。
  • SSRFでメタデータが取れる件。
  • 窃取されたクレデンシャルから、さらにIAMポリシーの不備で権限昇格される例。

    • Attach*Policyが付与されている場合
    • PassRole,CreateFunction,InvokeFunctionからの昇格
  • Pacuという攻撃デモンストレーションツール

    • これでPassRoleからCreateFunction,InvokeFunctionで昇格する
    • デモでは奪ったユーザーがPassできるRoleに test_lambda_adminがあり、 それがAdministratorAccessのPolicyがあるため、なんでもできてしまう
      • 奪ったユーザーのロールにAdminを付与する
    • さらに新規のアクセスキーを作ってバックドアにする
    • Admin権限があればSystemsManagerでOS侵入などもツールで簡単にできてしまう
  • アプローチ

    • 漏洩の防止、悪用の抑制、悪用の検知
    • IAMのベストプラクティスに従って対策しましょう
    • ツールも活用
      • AWS TA
      • classmethod insightwatch
      • netflix security monkey
    • 異常検知は「普段の状態」を知っている必要がある
      • 普段からログを見ること大事
      • GuardDutyも活用(とりあえず入れる、でもいいぐらい)

AWS AllStars

ちゃんと時間内に終わって感動したw

JAWS DAYS 2018メモ

keynote-1 A story of cloud journey with Community

  • 今回会場は1800人、スタッフ250人
  • ライブストリーミングあり(今回初か?)
  • 韓国の人結構来てた。
  • 楽しんで、登壇・アウトプットして、Make a Different。

Enterprise Serverlessを実現するための信頼性エンジニアリング

  • SERVERWORKS 照井さん
  • CNCFのServerlessの定義
    • 「使わないときはコストがかからない」→DynamoDBのキャパシティ予約は?
  • 信頼性とは?→RASIS
    • 自分で確保する
    • シンプルに考える
    • シンプルに保つ
    • マインドを変える、アプリケーション層で解決する
  • 結果はクライアントが取りに行く。だが、Push型ができるかが課題。AppSync?(Pushing via Websocket)
  • ACID特性がない店の対策→非正規化、条件付き書き込み、RDS使うなら非同期書き込み
  • テストは必ず書く →ワイルドサバンナ登場w
    f:id:morimop:20180311142145j:plain
    ワイルドサバンナ
  • 継続的なE2Eテストを、トレースできるIDを入れて

keynote-2 AWS Technical Evangelists Special talk session @D

  • Dトラックで聞くと静かだな(メインはA)
  • 機器トラブルで映像でないw
  • 復帰した

    AWSのアップデートにどう追いつくか

  • 興味のあるものを絞って、そこを追いかける、プラス2つか3つぐらいを見ておいて広げる
  • シャーディングがいい
  • 学び方を学ぶ
  • 好奇心を持って学ぶ

    AWSビギナーが学ぶには何がいいか?

  • は飛ばす(ぉ

    認定エンジニアになるために必要な学び方は?

  • アソシエイトはAWSわからなくても大丈夫
  • プロフェッショナルはAWSを詳しくても正答率85%
  • アーキテクチャを知る必要がある。知るには顧客の事例を観ること。
  • 認定で学ぶこととプロジェクトで学ぶことは違っている
  • クラウドの特徴はセルフサービスでハンズオンでできること。どんどん触って覚える。

    インフラエンジニアにおすすめするプログラミング言語は?

  • プログラミングの話をする場合、テキストエディタの議論があります、で笑い
  • 同僚がすでに使っている言語はなにか、それを学ぶべき
  • Python
  • Javascript
  • 言語はツール。大事なのは問題解決。
  • ビルド言語とスクリプト言語を1つづつやるのがいいのでは。

    学ぶのにおすすめのフレームワークやツールは?

  • Pythonです
  • 1つのものを何十年も使っていくということはありえない。継続的に学ぶ、ナレッジのリフレッシュが必要。
  • 日々新しいものを学ぶ時間を作ることをお勧めする。
  • Well-Architected Frameworkを学んでください

    5年後にもITエキスパートでいるには

  • Pythonですよ
  • 新しいものがでてきたとき、それは洗練されていないので、あれもできない・これもできないとなる
  • が、そこで心を閉ざしてしまうとその先に陳腐化する
  • なので、ちょっと足りないところでブログに書く。今後こうなっていくだろうということを書く。
  • 2014年当初、Lambdaを発表したときみんな興味はなかった。Workspacesとかのほうが注目された。
  • しかし今は違う。

    ある一人がk8sを学び、苦労してEC2上にk8sをデプロイした。その2ヶ月後、AWSのがEKSとFargeteを出した。自分は今後も同じことが起きるのかと恐れた。この人になんとコメントする?

  • 難しいこと言うね。
  • 顧客のニーズを見ていく。AWSも需要が大きいか、あるのかを見ている。例えば60%以上のワークロードでk8sが使われているということがわかれば、AWSはサービス化を検討するだろう。
  • 学んだことは無駄にならない。学んだことは付加価値として提供できるはず。自分たちで構築できることは選択肢になる。マネージドサービスを使うことに価値があると思えばつかっていただければいい。

AWSのコミュニティの他との違いは?

  • インフラのコミュニティは大体が暗い。AWSの日本のUGは明るかった。

    日本ではEC2の利用料が多いが、これは日本独特?

  • 最初はEC2だから、そこは変わらない。

    今後のITトレンドには何がありそう?(IoT,AI,ML,Edge computing以外)

  • 今までも色々あっtが、ハンズオンが大事だと思う。
  • 今後コードを書くことが減っていくかもしれないが、Jeffはいまもコードを書いて、ハンズオンしている。
  • みなさん自分自身のリージョンだけ使っているが、グローバルに展開できるサービスが増えている。他のリージョンへの展開もやってみるのはどうか。Grobal DynamoとかInter-region peeringとか。そういうトレンドが来るだろう。

ユーザー企業におけるサーバレスシステムへの移行

  • ダイソーの丸本さん
  • 大規模システムの課題
    • 影響範囲
    • テストが大きい
    • ベンダーの依存度が高くなる
  • 密結合の課題 システムが小さくても密結合では意味がない
  • インフラ管理の課題 アプリ、ビジネスに注力したい
  • スケールアップしたくない
    • 5,050店舗に7万商品を45日やったら159億レコード。
    • Oracleでやったら終わらなかったそうでw
  • アーキテクチャ
    • コマンドとクエリの分離
    • POSレジデータをS3に送り、SNSでトリガして回す感じf:id:morimop:20180311142756j:plain
      • サーバレスのオンプレ比較の話?
    • 「S3はファイルシステム」というのはどうだろうか。。
    • 「S3はファイル移動が失敗することがある」というか移動させないほうがいいだろうという気がする
    • オブジェクト名のハッシュの話
      • 定常的に100リクエスト/秒か瞬間的に800リクエスト/秒
  • SQSのキューイングパターンの話。冪等性。
  • SNSのPub/Subの話。
    • ダイソーでは基本的にFanoutパターン(Pub/Sub)としている
  • Lambdaの話。最大タイムアウトが5分の件。
    • コードの容量上限50MB。Pandasが40MBあるのでどうしたらいいの?という件。→解決策教えて。
      • AWS Batchじゃないかな?
  • DynamoDBの話。キャパシティ、というわかりにくい概念の話w
    • キャパシティ低めにするとLambdaの書き込み待ちが発生して、前述のタイムアウトにかかった話。
    • ダイソーでDynamoDBのキャパシティが100万円ぐらいかかる」ってすごいな。
    • Lambdaの同時期同数を制限して解決させた
  • 開発手法の話。Cloud9+Github+CircleCI+CloudFormation。
  • SourceTreeも使ってます
  • CFnで対応していない(例えばLambdaの同時実行数)は、CircleCIの最後でCLIを叩いている
  • 実験環境、開発環境、検証環境、本番環境とある
  • 自動テストの知見ほしい。テストコードのボリュームがやはりおおい。

    まとめ

  • アプリエンジニア的に、サーバレスにして「最初は大変だった」「制約があるので迷わない」
  • インフラエンジニアの評価は90点。満点じゃないのはAWSも結構サーバ落ちる。でもDesign for failur。
  • アプリケーションエンジニアの評価は90点。サーバレスにするとデザインが良くなってくる
    • イベント・ドリブンになるからかな??
  • 広島で働きたい社員募集!いっしょにやるひと募集!

コンテナを守る技術2018

  • JAWS-UGコンテナ支部の中丸さん
  • 「コンテナごとにIAMとSGを設定できるよ」知らんかった・・・そうなの???
    • awsvpcモードでできるそう。
    • Fargateもこの仕組。
  • ECSのタスク定義(Dokcerネイティブのオプションも多数ある)を厳密に定義しよう
  • docker-benchかけよう。AWS公式でLambdaで定期実行してアラームで通知しよう。
  • aquaというツール(商用)中丸さんおすすめ
  • NeuVectorのデモの動画
  • セキュリティポリシーはチームで、みんなでつくろう

API Meetup Tokyo #19 行ってきたメモ

API Meetup Tokyo #19 〜六本木ヒルズスペシャル〜に行ってきました

  • ヒルズにいるapigee@GoogleさんとPivotalさんなのでヒルズスペシャル!

Googleが提供する機械学習API

  • Google Cloud Platformチーム デベロッパーアドボケイト 佐藤 一憲(@kazunori_279) さん

  • GCP

    • AWSみたいなやつ」で会場ウケる
  • ニューラルネットワーク(NN)

    • 学習できる関数
    • 「やってみないとわからないが」
      • ゲームならチートや優良プレイヤーの検知
    • PlayGroundのデモ
      • 根気強く答えを教えてやると学習してくる
      • 単純な線形分割を1つのニューロンとすると、それを階層化する
      • ニューロンの結びつき(Weight)の強弱を変える
      • これをノンプログラミングでできるのが、いまのAIの盛り上がり
      • ニューロンの階層、各階層の数はセオリーがない
        • みんな試行錯誤でやっている・・
        • ルールベースでないところがNNの強み
          • cf.チェスのディープブルー
        • 要は データの特徴を探し出す
      • ニューロンの階層が深いと「ディープラーニング(DL)」
  • Googleでは10を超えるサービスでDL
  • Cloud Vision API
    • 一番使われているのはセーフサーチ(エログロ系のブロック)
  • Cloud Speech API

    • 文字起こしに使える
    • コールセンターなどの引き合い
    • さらにNatural Language API自然言語っぽく整形、感情分析
    • ツイートなどから製品や店舗の評判の分析にも
  • TensorFlow

    • よくある引き合い、既存のAPIでは対応できないもの
      • CTやレントゲンの画像からガンを見つけたい
      • 中古車の画像から車種などを特定したい
    • 機械学習で必要な数学の知識がなくても使えるのが強み
    • 結局NNは行列演算になるので、得意なのはGPU
    • スケーラビリティを念頭に置いたフレームワーク
    • 学習結果自体は数十MBぐらいの容量になるのでスマホにも入れられなくはないサイズ
    • コミュニティ、エコシステムの厚さ
    • SnapdragonがチップセットレベルでTensorFlowをサポートするなど
      • CPUでの認識より10倍以上早いというデモ
    • きゅうり農家さんの事例
    • からあげロボット
      • 食品をつかむのは難しい、というところを学習
    • DCGAN
      • お手本を多数インプットすると、それに近いものを生成してくる
        • アイドルの顔を多数見せて、アイドルっぽい顔写真の生成 こちら?
      • DeNAはプレイヤーごとのアイコン作成を実験中
    • GoogleではTensor用のASICチップを大量に入れているのでTensorに最適化されている
      • なのでGCP使うといいよ!
  • Cloud Machine Learning Engine(ML Engine)

Pivotalが推進するAPIとプラットフォームの活用

  • Pivotalジャパン 市村 友寛 さん
  • VMWareとGE出資でPivotal
  • Spring盛り上がっている!

  • アジャイルメソドロジーを覚えて帰っていってもらう活動もしている

    • Circle of Code
    • イデア→プラン→コード→ビルドパイプライン→デプロイ→フィードバック→(アイデアに戻る)
      • Pivotalで一連のアクティビティをサポートできるよ
  • 朝礼は9:06分

    • 9:00だと来ない、9:10だと遅れだすらしい
    • 円陣組んでやってる
  • イデアからプランへ

    • トーリーにする
      • コードを書き出せる程度に細分化するプロセス
    • Pivotal Tracker
      • SaaS型PJ管理ツール
      • 対抗はRedmineとかJIRA
      • トーリーを管理できるのがウリ
      • CloudFoundryのプロダクト管理にも活用
      • トーリーが1タスクになる
        • プロダクトマネージャーが承認して開始、受入もプロダクトマネージャー
          • (難易度を入れられるところも含めスクラムみたいだ)
        • トーリーの状態管理にUIもAPIもある
          • わかりやすい事例はGithub連携
          • コミットコメントにステータスとストーリIDを埋めるとWebhookでTrackerに
  • spring framework

  • Concourse (build pipeline)

    • CloudFoundryにおけるCI/CDの課題
      • 異なるアーキテクチャ、プラットフォーム、インフラでの動作確認やデプロイ
      • Jenkins職人作るぐらいなら・・・・
    • リソースにGitやS3、Docker、Bosh.ioつかえる
    • パイプラインの定義はYAMLで書ける
      • Concourseが動いていれば、どこでもパイプラインを持ち出せる
    • プロジェクトとパイプラインの統合
      • git -> Concourse -> Pivotal Tracker
      • APIを駆使して色々なものをパイプラインに任せられる
  • フィードバック

    • Spring Cloud Sleuth + Zipken
      • Zipkin
        • どのエンドポイントがボトルネックになっているか を一元的に表示
    • 何かが遅いというときに
      • Sleuthで仕込み
      • Zipkinで集める
  • Pivotal Labsでベストプラクティスをお教えしています!」

次回予告

  • 次回番外 福岡開催
    • 国家戦略特区である福岡
    • 5/19(金)@ヌーラボ福岡オフィス