行ってきました！AWS Dev Day Tokyo 2018！
今回は10/31のLT大会にて、
「AWS DMSで5億レコードを移行して知り得た勘所」というタイトルでLTさせて頂きました！
※LT資料については公開許可をもらっていないので、今のところは公開予定はありません。
参加したセッションについてレポートしていきます！
10/31(水) セッションレポート
14:00-14:40 The Twelve-Factor Appで考えるAWSのサービス開発
www.slideshare.net
- 環境変数
- AWS Parameter Store
- Rate Limitを考慮
- Rate Limitを超えるとスロットリングされ、リクエストがエラーを返却する。
- Rate Limitを把握し、上限緩和申請を行おう。
- Exponential Backoff And Jitter
- リトライに遅延(Backoff)とゆらぎ(Jitter)を導入する
- AWS SDKでの既に実装があるので参考にして実装する
- ビルド、リリース、実行の3つのステージを厳密に分離する。
- ステートレス／シェアードナッシング
- データストアはバックエンドサービスに
- ELBのスティッキーセッションは利用しない
- 共有データストアを作らない
- ポートバインディング
- スケールアウト
- 廃棄容易性
- 開発／本番一致
- ログ
15:00-15:40 外部に依存したコードもテストで駆動する
- まずは現状確認
- テスタビリティをこじあける
- aws-lambda-mock-context
- ランダムなテストの確認方法
- テストのことを考えてこなかったコードは、テストが書きにくい。
- 接続部(Seam)を作る
- 渡された変数でランダム性をぶっつぶす変更をテストコードに加える
- 設計はよくなっているか？
- リファクタリングが射程に入っていないテストコードになっちゃっている。
- テストでは品質は上がらない。テストはきっかけ。品質を上げるのはプログラミング。
- ビジネスロジックをLambdaから引き離す -> モデルを分離する
- 状態遷移もモデル自身が判断できるようにする
- アーキテクチャを定める
- 変化しやすいものに依存しないアーキテクチャ
- 基盤を扱う <-> 情報を扱う <-> 事実を扱う
- 変化しやすいものに依存しないアーキテクチャ
- レガシーサバンナ(w)
11/2(金) セッションレポート
10:20-11:00 マイクロサービス化デザインパターン
www.slideshare.net
- マイクロサービスとは
- システム全体の変更速度を上げる。
- アジャイル
- モノリシック・クラウド・DevOps
- NoOps = 運用作業込みでプラットフォーム化
- Cloud Native Architecture
- Kubernetes, ECS/EKS
- Istio
- 誰もが最初はマイクロサービスではなかった
- 2011年ぐらいに「マイクロサービス」と名付けられただけ
- 1チームで複数サービスを管理することは問題なし
- XPの開発プラクティスは基本
- テスト駆動、ペアプロ、リファクタリングなど
- 導入ステップ
- 段階を進めていく
- 最初のサービスを分割する。Monolithicから切り出す。
- サービス基盤を整備する
- サービスを管理する
- 段階を進めていく
- 最初のサービスを切り出す(Step1)
- リリースサイクルを早めたい場所を切り出す。= ビジネス視点で整理を行う
- 変更要求が多いところ
- 複数の機能を横断する場合があるため注意して整理
- WebAPI連携が定石
- URLベースの置き換え -> 共有メモリでの認証情報共有が課題
- データの分割は避け、共有データベースから
- メリット：コスト最適化
- デメリット：データベースに関する変更では同期が必要、テーブル共有やビュー経由共有
- 新サービスにはPaaSを採用 -> 運用作業が自動化されるが、PaaSの成約に従う必要がある
- リリースサイクルを早めたい場所を切り出す。= ビジネス視点で整理を行う
- 金が儲かるか儲からないかという話でマイクロサービスを切り出すことが大事！？
- エンジニアがどうだとかそういう話ではない。サービスの分割はビジネス視点で決定すること。
- 技術的に無理しすぎない。
- サービス基盤を整備する(Step2)
- 疎結合に保つための基盤づくり
- 認証のSSO化(OpenID Connectなど)
- ログ基盤の導入
- 非同期キューの導入
- DBインスタンスの分離(疎結合化) - 不整合をどうするのかが大事
- 環境設定の外部注入
- 分割と集約のバランスを考える
- 疎結合に保つための基盤づくり
- サービスを管理する(Step3)
- コンテナ化
- バッチサーバの廃止 -> 起動するタイミングでノードを手配する
- サービスメッシュの導入
- イベントソーシングの導入
- コンテナ化
- 新しい技術を使いすぎてオーバーキルになりがちなので気をつけましょう！ということで・・。
13:20-14:00 マイクロサービス時代の認証と認可
www.slideshare.net
- 認証と認可の基礎知識
- 認証 通信の相手が誰なのか確認
- 認可 リソースアクセス権限を与えること
- 401:認証の失敗, 403:認可の不足
- WHAT YOU ARE, WHAT YOU HAVE, WHAT YOU KNOW
- Basic認証(disられ杉), Digest認証(API認証には不向き), リクエスト署名(標準化が足りない), OAuth 2.0(複雑さを覚悟せよ)
- リソース三役が分離している？ -> 静的・無期限クレデンシャルを許容できる？ -> 独自仕様でいい？策定・実装できる？
- ユーザの認証とシステムの認証
- APIの制御について、「データは消費者のモノ説」という考え方で設計
- Aさんからの許諾があった場合のみという考え方
- OAuth 2.0とマイクロサービス玉突きの認証認可
- 所有者, 利用者, 管理者という考え
- ユーザーと、その権限委譲を受けたクライアント両者の認証が可能になる。
- ユーザーの介在しないクライアント単体によるアクセス認証も可能です。
- 玉突きアクセス
- Access token propagation(S3がWebからだと錯覚する)
- Client credentials grant(ユーザーの後ろ盾情報が消える)
- OpenID Connect 1.0とマイクロフロントエンド
- AWSはMSAのお手本
- 統一されたLook and Feel
- SSO(Single Sign-On)
- 認証サーバーに対するログインセッションが良い
14:20-15:00 Backends For Frontends 入門
- BFFとは
- フロントエンドのためのバックエンドサーバー
- Sam Newman
- BFFがやること
- API Aggregation
- Session Management
- (Server Side)Rendering
- File Upload
- WebSocket/LongPolling/SSE
- Twitter
- 最初はMonolith
- Scala化 -> MicroServices
- to BFF
- Netflix
- 2012にはBFFを活用 : Client Adapter Code
- Recruit Technologies
- BFFをNode.jsで構築
- BFF導入するとき
- 疎結合にして今後のエンハンス速度を上げたい
- 先程あげたユースケースのような処理が必要
- レガシーなシステムが既に存在しており、それを上にかぶせて段階的にリアーキテクトしたい
- しないとき
- フロントとバック両方を開発できる人が多い
- マーケットインを速めることを優先する
- 上述したユースケースが求められることが少ない
- BFFのアンチパターン
- Dividing frontend from backend is an antipattern
- なわばり意識的な
- BFFは組織の接合点になりやすい
- スパースコミュニケーション(これありそう。特に仲が悪い場合。)
- モックサーバーを作り認識齟齬を埋める
- インフラレスポンシビリティ
- そもそもBFFを誰がお守りするのか
- A : 全員
- ビッグバンジョイント
- APIのリクエスト・レスポンスは想定通りじゃない
- 確実に想定外の問題は起きる
- Dividing frontend from backend is an antipattern
15:00-15:40 Microservicesの始め方、あるいは始めるべきか
- Microservicesによってスピード感を持つことが必要。
- スタートアップはオーナーシップが必要なので、マイクロサービスが必要ない。
- メルカリも100人こえてる辺りから、Microservicesを始めた。
- 組織とシステムを分ける必要があるのか -> インフラエンジニアを持てないチームが出てきた場合の問題は？
- 統一したチームでツールを作り、インフラを構築したりスケールできるようにする。Self Service Tool的な。
- メルカリはMicroservicesでGCPを使っている。<- terraformです。
16:00-16:40 コンテナ業界の尖った人達による、技術から組織までのぶっちゃけトーク ~こわくない、こわくないよ~
- 組織に問題があるから、それがMicroservicesで解決できるとは思わないほうがいい。
- 特に大きくてサービスにとって重要なサービスを切り出す。
- 切り出すきっかけ -> Codeベースが大きすぎて修正した時の影響範囲とか
- 手を入れやすくするという面でMicroservicesはエンジニアにとっての福利厚生かもしれない。
- ECSとKubernatis
- KubernatisはVersion1でProduction Readyだった。
- 複雑な要件がなくシンプルで導入できそう、APIが標準化されていた。
- 少人数で運用だけで回したかったのでKubernatisを選んだ。
- KubernatisはVersion1でProduction Readyだった。
- その時、その時の選択で決まる・・と。
- メルカリKubernatisが99%・・。
- 知見が溜まっているから初期コスト回避のためにもKubernatisを利用することが多い・・。
- メルカリKubernatisが99%・・。
- EKSが出てきた時にどうする的な話はあった。
- ECSと比較して、コアコンポーネントの機能的には差はない。
- 大きな差は周りのエコシステム。当時はモヒカンしか生き残れない世界からECSを使っていた的な。
- 改めて見直しをしてもよいけど、積極的にECSから乗り換えるような議論にはなっていない。
- AWSでこういうツールほしい的な話
- FargateをEC2上でホスティングする何か？
- EKSでWorkerノードもマネージドしてほしい的な。
- EKSはアップデートが怖いので、その辺りをマネージサービスでカバーしてくれると嬉しい。
- KubernatisのノードのCanalyアップデートがほしい的な。
- KubernatisはインフラのRailsのようなもの・・！？
- 今後のキャリアは？
- -> スタートアップとか、自分のサービスとか
- -> エンジニアとしてできることを増やしていくこと
- -> 使う側じゃなくて作る側に回ってみたい
- -> 会社が進むための技術力の見識や知識
参考サイト
所感
初めてAWS Loft Tokyoに行きました！
目黒セントラルビルの17階から見る眺めは素晴らしいの一言！
毎日こんな景観を見ながら仕事できるといいのになぁ。
Microservicesの憑き物が落ちた感じがした。
特に「マイクロサービス化デザインパターン」のセッションにて、
マイクロサービスがbuzzワードになっている現状と、具体的なマイクロサービスの
導入アプローチを知ることができたので、何か憑き物が落ち感があります。
既にAPIやキューを使った疎結合を実現しており
密結合はほぼ存在しないアーキテクチャが多い。
そういった状況からサービスメッシュを使ってハンドリングしやすくするのが
今のマイクロサービスアーキテクチャのトレンドであって、
マイクロサービスになっていないわけではない。
と言える気がするくらいには憑き物が落ちました。
結局一番大事なことは、事業として成り立っているかどうかだと思う。
その後にリファクタリングしていけばいいじゃん？的な。
スピード感はやっぱり大事だよね。
参加した皆様、お疲れ様でした！
以上です！
