オープンバンキング/API勉強会(2019-09-27)いってきたメモ
イベントページ
オープニング(MF瀧さん)
- 協会挨拶をざっくりと
- なにかで喧嘩がおきたとかそういうはなし?もでて一部の笑いを誘う
OBIのレポートを見ながら話す
- MFの瀧俊雄取締役
- レポートの立て付けから
- 参考にはするべきだけどコピーして使えるものじゃないよね
- イギリス 国有化したけどちっとも黒字にならない
- LIBO操作の件とか(なつかしい)
- イギリスの銀行の寡占状態
- 日本と比較してだいぶん競争がないので手数料がすごく高い
- もっと競争すべきだ、というバイアスが掛かっている点に注意!
- MyDataの話
- 取引がクリアだと健全だよね
- 隣の家がいついくらで買われたかがわかる
- PSD2の話
- でたのは2016年、Activateされたのが2017とか2018
- P.12、13あたりにこれらの施策がWorkしたのかが述べられている
- OBIEってなんだ?
- CMS OrderとPSD2との違いと共通点の図解
- 結果としてどんなプレイヤーが生まれたか?もレポート
- Open Banking Standardの成果は
- ちゃんと更新もされている
- 日本でも***が標準作ったが、送金には触れてなかったり、ざっくりしていて実際は方言があったりしている
- それにそって実装している訳ではない
- とはいえ、ベンダーの数ぐらいしかパターンがないので、がんばればいける(さすがMFさん)
- Open Banking Standardの成果は
- そしてOpen Financeへ
- そしてPremium API
- まとめ
- これまでの制度のなかで、失敗したことは失敗したとして見直しているところがすごい
- QA
- OBIEの経済効果は?
- まだそこまでになってない、収益がでてない、これから
- 基幹系に突っ込んでるお金と同じだよね、という議論も
- CASSは霞が関どうみてる?
- まぁ日本では強大な権限によって潰されるでしょうね(笑い
- 自然発生的にでるかもしれない
- 遺言とかそっちのがいいんじゃないかな
- APIになってMFで、ドロップ率あがったとかあります?銀行の画面がイケてないとかそういうのがある
- あんまり聞いてない。かわらないんじゃ?
- EUでは難民の口座開設はどうなっている?本人確認とか。
- 確率論でみているんでは。取引額が小さければザルとか
- ちょっと高度でお答えできない
- 課金の話は解決しない。当局が~
- 当局は関係ないんじゃない?
- 日経電子版で本日でたAPIの総覧で、データポータビリティが解決するね的なコメントした
- 電代業はパシリですよ!お金取ってきて親玉がそれを全部取ったら、そりゃないよ!エンドユーザーに課金するの?おかしいよね!
- CASSが日本に来るのにどれくらいかかる?
- こないんじゃない?パシリがいればできるし
- イギリスしかやってないし
- raisinというのはある https://www.raisin.com/
- 資金移動APIとeKYCが軽くなった世界では、実質CASSできるよね
- OBIEの経済効果は?
Authlete工藤さん
- 英国オープンバンキング技術仕様の概要
- スライドは公開します、とのこと(今日はうまくいってないらしい)
- API Onboardingにも仕様・ガイドラインを定めている
- Dynamic Client Registration
- Open Banking Directory
- FAPIとCIBAの上に、Read/Write DataのAPIがのっている
- FAPIの話
- CIBAについて
- 「CIBA見たことある人?あ、半分ぐらいいますね。じゃ話さなくっていいですかね?」笑い
- CIBAじゃないやつ=Redirect Flow
- Decoupled Flow
- 「CIBA Pay(ダッサ」のユースケース
- R/W Data APIの話
- API設計でよくやる話がベースとしてまとまってる仕様
- 特にsecurity & Access Controlがいい感じ
- 例えばOAuthでいうScopeで「この取引だけ」にするには?
- Intentで解決!
- この”Intent”の標準化
- これがないと、顧客体験がバラバラに
- Monzoというチャレンジャーバンクはマジックリンクでログインできるらしい「えっ銀行でそれやるの?」w
- Customer Experience Guideline
- OpenBankingのカスタマージャーニー=TPPとASPSPの連携
- 原則を定めている
- 例)Browser based redirection - PIS
- こういう表示をしてくださいね、というガイドを定めている!!
- 例)App based redirection
- OB DirectoryとDynamic Client Registrationのはなし
- OB Directoryの概念図。個々にやるとメッシュ構成になるので・・・・
- (これ、日本にはないのか??)
- TPPの登録を手でやるのではなく、自動でやる
- OB Directoryの概念図。個々にやるとメッシュ構成になるので・・・・
- 実装について
- めんどうくさいところはAuthleteにやらせましょう!(笑い
- FAPI認定、CIBA認定プログラムを取っている製品を使いましょう
- まとめ
- QA
Appendix
- レポート本文はこちら https://www.openbanking.org.uk/wp-content/uploads/open-banking-report-150719.pdf
- 2014年のHMTレポートはこちら https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/382273/141202_API_Report_FINAL.PDF
- AISP/PISP の一覧はこちら https://www.openbanking.org.uk/customers/regulated-providers/
- CMAのレポート(の解説ブログ)はこちら https://moneyforward.com/mf_blog/20160812/cma/
- OBIEのカスタマーエクスペリエンスガイドライン https://www.openbanking.org.uk/wp-content/uploads/Customer-Experience-Guidelines.pdf
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的な発想かな?
- HTMLやスクリプトのサイズに制限を設ける
- Chrome UX Report!
- Google Search Report
- Lighthouse!LightWallet!
- 事例)proxx.app
- Chromeエンジニアが開発、廉価な端末でも高速!
- 3G回線でも快適
- ワーカースレッドを活用している
- Chromeエンジニアが開発、廉価な端末でも高速!
- Portals機能を使ったトランジション、となりのヤングジャンプとはてな
- PWAの話
- Trusted Web Activities
- PWAをAndroidアプリに埋め込む
- Desktop PWA
- huluの例
- WebAuthnの話
- Yahoo!JAPANの事例
- もう採用していたっけ?さすがだ
- 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
- 使い分けチャートあるよ!見てね!
- https://cloud.google.com/serverless-options/?hl=ja
- ステートレスじゃないアプリは出てこないよ!ww
- Functions
- イベントドリブン
- ランタイム制約あり
- AppEngine
- 対抗はHeroku、Elastic Beanstalk
- こちらもランタイム制約あり
- Firestore、CloudMemoryStore、Cloud Tasksを組み合わせてFront/BackのAppEngineを連携させよう
- デプロイメントオプションあるよ!
- B/G,Canary,A/B
- 裏はDockerなのでDocker制約はある(らしい)
- CloudRun
ストレージ
- Firestore
- NoSQL、トランザクションも使える
- Nativeモード(Realtime)とDatastoreモード
- CloudSQL
- MySQLとPostger
- SQL ServerはAlpha
- Spanner
- 水平スケールできる
- CAP定理を超える謎の技術
- 既存DBとの整合性、リージョン間レプリケーションの提供エリアは注意
- 水平スケールできる
非同期処理
- Cloud Tasks
- Pub/Subとの違い
- スケジュール実行もできる!
- レート制御もできる!
- タスクの再試行ができる!
- HTTP/S Auth(IAM)ターゲット!
- Pub/Subとの違い
静的コンテンツ
- 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
- などなど
- 「パフォーマンスバジェットのご紹介」読もう
- まずはレポーティングに使っている
- 機能追加するときにその分なにを削る?みたいなツールにもなる
- パフォーマンス計測ツール
- Google Fundamentals参照
19:50 ~ 20:20 インフラ管理不要の Firebase と GKE で実現するモバイルアプリ開発 株式会社Ginco 西川 達哉 さん
- 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書くのがわかりやすくていい
- 以下はTwitterより
- アクセスキーでアクセスできちゃうので・・・・の話
- その他イベントドリブン
- 更新されたらPush通知とか
- クラッシュログをGithubのIssueとSlack通知(!?)
- Issueすごいことになりそうだけどな・・・
- 行動履歴とか
- 強制アップデートとか
- RemoteConfig
- Stackdriver
- GKEとCloudFunctionsは自動
- いいなぁ
- Alert設定、Error Reporting
- GKEとCloudFunctionsは自動
まとめ
- Firebaseはクライアントエンジニア主体の開発体制にできるのがいい!
JAWS Days 2019メモ
「AWS IoTのベストプラクティス」それホント? 10:10~
事例:マルチファンクションライト
- スピーカーもついてる、家電の操作もできる
1 デバイス証明書の管理
2 WebAPIも使いたいんだけど
余談:AWS IoTのお値段が高い!(高かった)話
3 IoT CoreのLogging
4 大量のメッセージ送信
- 緊急地震速報みたいなユースケース
- コネクションあたりの秒間Publish数の上限緩和はできない
- アカウント単位の秒間Publish数は相談可能とのこと
- なので、Topicを分けるのがプラクティス
- 以前Nintendo Switchの人が同じようなこと言ってたな
- 送りっぱなしでACKは返さない、送ったあとAPI叩くとかすると受け側が死ぬので注意!
5 コネクションの切断検知
- シーリングライトの壁スイッチ問題
- スイッチオフすると主電源が落ちる
- LWTをサポートしているのでこれを拾ってステータスをレポートする!
- Alexaではこの対応ができてないとスキルの審査が通らないよ
- ただリアルタイムではないので・・・
- シーリングライトの壁スイッチ問題
6 Shadowの使い方
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横井さん
- 解約時のリソース削除は手動でやりたくない、たしかに。
- セキュリティテストの自動化 シノプシス伊藤さん
- Black Duck https://www.blackducksoftware.com/
至高の 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侵入などもツールで簡単にできてしまう
アプローチ
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
- 自分で確保する
- シンプルに考える
- シンプルに保つ
- Functionの数が増えるのを恐れない。恐れるべきは複雑なアーキテクチャ。
- マインドを変える、アプリケーション層で解決する
- 結果はクライアントが取りに行く。だが、Push型ができるかが課題。AppSync?(Pushing via Websocket)
- ACID特性がない店の対策→非正規化、条件付き書き込み、RDS使うなら非同期書き込み
- テストは必ず書く →ワイルドサバンナ登場w
- 継続的な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
- アーキテクチャ
- SQSのキューイングパターンの話。冪等性。
- SNSのPub/Subの話。
- ダイソーでは基本的にFanoutパターン(Pub/Sub)としている
- Lambdaの話。最大タイムアウトが5分の件。
- コードの容量上限50MB。Pandasが40MBあるのでどうしたらいいの?という件。→解決策教えて。
- AWS Batchじゃないかな?
- コードの容量上限50MB。Pandasが40MBあるのでどうしたらいいの?という件。→解決策教えて。
- DynamoDBの話。キャパシティ、というわかりにくい概念の話w
- 開発手法の話。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 〜六本木ヒルズスペシャル〜に行ってきました
Googleが提供する機械学習API
Google Cloud Platformチーム デベロッパーアドボケイト 佐藤 一憲(@kazunori_279) さん
-
- 「AWSみたいなやつ」で会場ウケる
ニューラルネットワーク(NN)
- Googleでは10を超えるサービスでDL
- データセンターの冷却コントロールをDLで
- クラシックピアノの曲生成
- 著作権者がいないのでBGMにいいかも
- Cloud Vision API
- 一番使われているのはセーフサーチ(エログロ系のブロック)
Cloud Speech API
TensorFlow
- よくある引き合い、既存のAPIでは対応できないもの
- CTやレントゲンの画像からガンを見つけたい
- 中古車の画像から車種などを特定したい
- 機械学習で必要な数学の知識がなくても使えるのが強み
- 結局NNは行列演算になるので、得意なのはGPU
- スケーラビリティを念頭に置いたフレームワーク
- 学習結果自体は数十MBぐらいの容量になるのでスマホにも入れられなくはないサイズ
- コミュニティ、エコシステムの厚さ
- SnapdragonがチップセットレベルでTensorFlowをサポートするなど
- CPUでの認識より10倍以上早いというデモ
- きゅうり農家さんの事例
- からあげロボット
- 食品をつかむのは難しい、というところを学習
- DCGAN
- GoogleではTensor用のASICチップを大量に入れているのでTensorに最適化されている
- なのでGCP使うといいよ!
- よくある引き合い、既存のAPIでは対応できないもの
Cloud Machine Learning Engine(ML Engine)
- キューピーさんの事例
- ベルコンベアーで運ばれる食品の中に異物があるかの判定
- AUCNETさん(中古車)の事例
- キューピーさんの事例
Pivotalが推進するAPIとプラットフォームの活用
- Pivotalジャパン 市村 友寛 さん
- VMWareとGE出資でPivotal
Spring盛り上がっている!
朝礼は9:06分
- 9:00だと来ない、9:10だと遅れだすらしい
- 円陣組んでやってる
アイデアからプランへ
Concourse (build pipeline)
フィードバック
- Spring Cloud Sleuth + Zipken
- Zipkin
- どのエンドポイントがボトルネックになっているか を一元的に表示
- Zipkin
- 何かが遅いというときに
- Sleuthで仕込み
- Zipkinで集める
- Spring Cloud Sleuth + Zipken
「Pivotal Labsでベストプラクティスをお教えしています!」
次回予告
- 次回番外 福岡開催
- 国家戦略特区である福岡
- 5/19(金)@ヌーラボ福岡オフィス