ヤサイブログ

I'll keep hacking on fun. ~ 学びよ、加速しろ ~

AWS Dev Day Tokyo 2018 行ってきました!参加レポート

行ってきました!AWS Dev Day Tokyo 2018!
f:id:yasay:20181113081600j:plain:w350

今回は10/31のLT大会にて、
AWS DMSで5億レコードを移行して知り得た勘所」というタイトルでLTさせて頂きました!
※LT資料については公開許可をもらっていないので、今のところは公開予定はありません。

参加したセッションについてレポートしていきます!

10/31(水) セッションレポート

14:00-14:40 The Twelve-Factor Appで考えるAWSのサービス開発

www.slideshare.net

  • Rate Limitを考慮
    • Rate Limitを超えるとスロットリングされ、リクエストがエラーを返却する。
    • Rate Limitを把握し、上限緩和申請を行おう。
  • Exponential Backoff And Jitter
    • リトライに遅延(Backoff)とゆらぎ(Jitter)を導入する
    • AWS SDKでの既に実装があるので参考にして実装する
  • ビルド、リリース、実行の3つのステージを厳密に分離する。
  • ステートレス/シェアードナッシング
    • データストアはバックエンドサービスに
    • ELBのスティッキーセッションは利用しない
    • 共有データストアを作らない

15:00-15:40 外部に依存したコードもテストで駆動する

speakerdeck.com

  • まずは現状確認
  • テスタビリティをこじあける
  • aws-lambda-mock-context
  • ランダムなテストの確認方法
    • テストのことを考えてこなかったコードは、テストが書きにくい。
    • 接続部(Seam)を作る
      • 渡された変数でランダム性をぶっつぶす変更をテストコードに加える
  • 設計はよくなっているか?
    • リファクタリングが射程に入っていないテストコードになっちゃっている。
    • テストでは品質は上がらない。テストはきっかけ。品質を上げるのはプログラミング。
  • ビジネスロジックをLambdaから引き離す -> モデルを分離する
  • 状態遷移もモデル自身が判断できるようにする
  • レガシーサバンナ(w)

11/2(金) セッションレポート

10:20-11:00 マイクロサービス化デザインパターン

www.slideshare.net

  • マイクロサービスとは
    • システム全体の変更速度を上げる。
    • アジャイル
    • モノリシック・クラウド・DevOps
    • NoOps = 運用作業込みでプラットフォーム化
  • Cloud Native Architecture
  • 誰もが最初はマイクロサービスではなかった
    • 2011年ぐらいに「マイクロサービス」と名付けられただけ
    • 1チームで複数サービスを管理することは問題なし
    • XPの開発プラクティスは基本
  • 導入ステップ
    • 段階を進めていく
      1. 最初のサービスを分割する。Monolithicから切り出す。
      2. サービス基盤を整備する
      3. サービスを管理する
  • 最初のサービスを切り出す(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 入門

speakerdeck.com

  • 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のリクエスト・レスポンスは想定通りじゃない
      • 確実に想定外の問題は起きる

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が99%・・。
      • 知見が溜まっているから初期コスト回避のためにもKubernatisを利用することが多い・・。
  • EKSが出てきた時にどうする的な話はあった。
    • ECSと比較して、コアコンポーネントの機能的には差はない。
    • 大きな差は周りのエコシステム。当時はモヒカンしか生き残れない世界からECSを使っていた的な。
    • 改めて見直しをしてもよいけど、積極的にECSから乗り換えるような議論にはなっていない。
  • AWSでこういうツールほしい的な話
    • FargateをEC2上でホスティングする何か?
    • EKSでWorkerノードもマネージドしてほしい的な。
    • EKSはアップデートが怖いので、その辺りをマネージサービスでカバーしてくれると嬉しい。
    • KubernatisのノードのCanalyアップデートがほしい的な。
  • KubernatisはインフラのRailsのようなもの・・!?
  • 今後のキャリアは?
    • -> スタートアップとか、自分のサービスとか
    • -> エンジニアとしてできることを増やしていくこと
    • -> 使う側じゃなくて作る側に回ってみたい
    • -> 会社が進むための技術力の見識や知識

所感

初めてAWS Loft Tokyoに行きました!

f:id:yasay:20181113081515j:plain
目黒セントラルビルの17階から見る眺めは素晴らしいの一言!
毎日こんな景観を見ながら仕事できるといいのになぁ。

Microservicesの憑き物が落ちた感じがした。

特に「マイクロサービス化デザインパターン」のセッションにて、
マイクロサービスがbuzzワードになっている現状と、具体的なマイクロサービスの
導入アプローチを知ることができたので、何か憑き物が落ち感があります。

既にAPIやキューを使った疎結合を実現しており
密結合はほぼ存在しないアーキテクチャが多い。
そういった状況からサービスメッシュを使ってハンドリングしやすくするのが
今のマイクロサービスアーキテクチャのトレンドであって、
マイクロサービスになっていないわけではない。
と言える気がするくらいには憑き物が落ちました。

結局一番大事なことは、事業として成り立っているかどうかだと思う。

その後にリファクタリングしていけばいいじゃん?的な。
スピード感はやっぱり大事だよね。

参加した皆様、お疲れ様でした!
以上です!