「Microservice Meetup vol.6」に参加してきました

microservice on AWS

  • 西谷さん(AWS)

Microservice Architecture

  • 分散型
    • DBも
    • 開発も
    • 運用も
    • デプロイも
  • 独立型
  • 1つのことをうまくやる
  • 多言語
    • それぞれ最適なツールを選択できる
  • PolyglotPersistence
    • RDBMSが常に最適とは限らない
    • 最適なものを選ぶ
  • ブラックボックス
  • DevOps
    • サービスを構築する責任を負うチームは本番環境の運用保守に対しても責任を負う
    • DevOpsがマイクロサービスにおける主な組織原理

マイクロサービスのメリット

  • 俊敏性
    • 狭い範囲のコンテキストで活動できる
    • ビルド/テスト/デプロイの時間が短い
  • イノベーション
  • 品質
    • 小さく分割してるから
  • 拡張性
  • 可用性
    • 障害の分離の実装が容易

マイクロサービスの課題

  • 分散型を扱う難しさ
    • システムの数が膨大になる
      • サーバコストが単純に増加するだけになってしまうことも
    • コンポーネント間のやりちりが増加しレイテンシ増
    • ネットワーク/帯域に問題あると致命的
  • 移行
    • モノリシックからの移行は難しい
  • 組織
    • マイクロサービスに適した組織体制にする必要性
  • アーキテクチャの複雑さ
    • 非同期
    • データ整合性
    • 認証
  • 運用面
    • 課題はたくさんある

マイクロサービスとAWS

  • コンテナ
    • Amazon ECS
      • コンテナを管理してくれる
      • 管理ノード不要の安定かつこうパフォーマンス
  • データストア
    • インメモリ
    • RDBMS
    • NoSQL
      • 整合性よりもパフォーマンスと可用性
      • 水平方向のスケール対応が多い
      • テーブルの結合ができないからアプリのロジック増えるかも
  • API
    • API Gateway
      • 複数バージョンとステージ
      • Cognito
      • モニタリング
      • Lambdaと連携
  • サーバレスマイクロサービス
    • サーバがないに越したことはない
    • スケーリングと高可用性
    • API Gateway の先がLambda

サービスディスカバリ

  • ALBベース
    • ALBが死活監視
    • アクセスはALB経由
  • DNSベース
    • R53
  • ECSのイベントストリーム
    • CloudWatchへ通知
    • 受信をトリガーにLambdaよぶ
    • lambdaがRoute53へ通知して増えたコンテナを登録
  • DynamoDBベース
    • 特定の何かが更新されたらそれをきっかけに処理を動かすとか

イベントベースなアーキテクチャ

  • 結果整合性
  • Dual Write Ploblem
  • 状態を記録するのではなく状態の変更というイベントを記録
    • イベントの永続化
    • Kinesis
      • ストリームのサービス
  • モニタリング
    • CloudWatch
      • ログに一元化
        • S3へ
        • CloudWatch LogsとKibanaを連携でログ検索分析
  • 分散トレース
  • ログ分析
  • キャッシング
  • ロットリング
  • リトライ
    • 復帰時に一斉にリトライされない仕組み
    • Exponential back off

まとめ

  • マイクロサービスが分散型アプローチ

クラウド電子カルテシステムとマイクロサービス

  • 加藤さん(エムスリー)

FrontEndからみるmicroserviceとBackendからみるmicroservice

今日の話

Phase1

  • アプリが小さかった
  • 新しいサービスをたくさん作ってた
  • 1つのアプリで管理が大変に
  • 機能別に分ける
  • API化(frontとback分離)

Phase2

  • Spring+thymeleaf - SpringBoot

  • ドメインを分析してAPIを共通化

  • restに準じたAPI
    • 巨大なAPIが整理された
    • API設計を考える風土が根付いた
  • APIの整備でマイクロサービスっぽくなってきた
  • オーケストレーションAPIが複雑
  • フロントが日本と海外で微妙に違う
    • それを吸収するために複雑になってた
    • ほとんど一緒なのに微妙に違うとか
  • From/Backの責任範囲が曖昧だった
  • モバイル/Web/外部サービス等いろんなとこから使われる
  • マイクロサービスっぽくなってきたけどその影響で品質落ちてきた

Phase3

言語の再設定

組織

  • フロント中心に
    • Reactエンジニア20人くらい(日本人は2,3人)
  • フロントエンドのチームがたくさんできた
  • API Gatewayのチームもできた

UIコンポーネントとマイクロサービス

Responsibility

  • フロントでどこまでやるかはっきりさせた

まとめ

  • バックエンド
  • フロントエンド
    • UIに最適化したレスポンスがいい

"マイクロサービスはもう十分"か?