microservice on AWS
- 西谷さん(AWS)
Microservice Architecture
- 分散型
- DBも
- 開発も
- 運用も
- デプロイも
- 独立型
- 1つのことをうまくやる
- 特定のドメインに焦点
- 多言語
- それぞれ最適なツールを選択できる
- PolyglotPersistence
- RDBMSが常に最適とは限らない
- 最適なものを選ぶ
- ブラックボックス
- DevOps
- サービスを構築する責任を負うチームは本番環境の運用保守に対しても責任を負う
- DevOpsがマイクロサービスにおける主な組織原理
マイクロサービスのメリット
- 俊敏性
- 狭い範囲のコンテキストで活動できる
- ビルド/テスト/デプロイの時間が短い
- イノベーション
- 品質
- 小さく分割してるから
- 拡張性
- 可用性
- 障害の分離の実装が容易
マイクロサービスの課題
- 分散型を扱う難しさ
- システムの数が膨大になる
- サーバコストが単純に増加するだけになってしまうことも
- コンポーネント間のやりちりが増加しレイテンシ増
- ネットワーク/帯域に問題あると致命的
- システムの数が膨大になる
- 移行
- モノリシックからの移行は難しい
- 組織
- マイクロサービスに適した組織体制にする必要性
- アーキテクチャの複雑さ
- 非同期
- データ整合性
- 認証
- 運用面
- 課題はたくさんある
マイクロサービスとAWS
サービスディスカバリ
- ALBベース
- ALBが死活監視
- アクセスはALB経由
- DNSベース
- R53
- ECSのイベントストリーム
- CloudWatchへ通知
- 受信をトリガーにLambdaよぶ
- lambdaがRoute53へ通知して増えたコンテナを登録
- DynamoDBベース
- 特定の何かが更新されたらそれをきっかけに処理を動かすとか
イベントベースなアーキテクチャ
- 結果整合性
- Dual Write Ploblem
- 状態を記録するのではなく状態の変更というイベントを記録
- イベントの永続化
- Kinesis
- ストリームのサービス
- モニタリング
- CloudWatch
- ログに一元化
- S3へ
- CloudWatch LogsとKibanaを連携でログ検索分析
- ログに一元化
- CloudWatch
- 分散トレース
- ログ分析
- キャッシング
- スロットリング
- リトライ
- 復帰時に一斉にリトライされない仕組み
- Exponential back off
まとめ
- マイクロサービスが分散型アプローチ
- アプリと組織をスケール
- アーキテクチャと運用の負担増
クラウド型電子カルテシステムとマイクロサービス
- 加藤さん(エムスリー)
FrontEndからみるmicroserviceとBackendからみるmicroservice
今日の話
- 楽天トラベルの話
- 100以上のフロントアプリ
- エンジニア150人
- マイクロサービスでできている
- https://www.slideshare.net/rakutentech/springspring-day-2016
Phase1
- アプリが小さかった
- 新しいサービスをたくさん作ってた
- １つのアプリで管理が大変に
- 機能別に分ける
- API化(frontとback分離)
Phase2
Spring+thymeleaf - SpringBoot
- restに準じたAPIへ
- APIの整備でマイクロサービスっぽくなってきた
- オーケストレーションAPIが複雑
- フロントが日本と海外で微妙に違う
- それを吸収するために複雑になってた
- ほとんど一緒なのに微妙に違うとか
- From/Backの責任範囲が曖昧だった
- モバイル/Web/外部サービス等いろんなとこから使われる
- マイクロサービスっぽくなってきたけどその影響で品質落ちてきた
Phase3
言語の再設定
組織
UIコンポーネントとマイクロサービス
- StoryBookでUI管理
- ドメインの情報を含むものもコンポーネント管理している
- 通信処理とかもコンポーネントに閉じ込める
- コンポーネントをまたがるロジックもたまにあってそういう時はBFFとか必要になってきた
Responsibility
- フロントでどこまでやるかはっきりさせた
