「Microservices Meetup vol.6」に行ってきた

2017/1/19のデイリーストックランキングにランクインしました。

---

いままでの。
「Microservices Meetup vol.2」行ってきたメモ。
「Microservices Meetup vol.4」に行ってきた
Microservices Meetup vol.5 (API Gateway & BFF) 行ってきた（速報）

図らずして1回おきに参加してますね。
vol.5に参加してたの忘れてたｗ

Connpassのイベントページ

少し間が空いてしまったがまた定期的に開催していきたいです。
登壇したいよーって人は直接リプ投げてください
by @qsona さん

Microservices on AWS by @Keisuke69 さん

Keisuke Nishitani @ AWS

Specialist Solutions Architect

サーバーレスアプリケーション開発ガイド 2月発売

マイクロサービスのポイント

• 管理運用まで含めて分散型
• 各コンポーネントが独立している
  • 単独で実行できないのは適切に設計されていない

独立して分散していると負荷の高い機能の単位でスケールさせられる＝コスト効率が良い

• 一つのことをうまくやる
  • 複雑化したら分割する

• 多言語

  • チーム（機能）にはそれぞれの問題に対して適切なツールを選択する自由がある
  • OS、言語、各種ツールに至るまで最適なアプローチを目指せる

• 検索：Elasticsearch / Solr

• ソーシャル：グラフDB

• ログデータ：Cassandra

• セッション：Redis

†AWSでは：AWSには100ちょいのサービスがあって、その中で更にチームが分かれている。
各チームに社内標準の開発プロセスは存在しない。

• ブラックボックス
  • 詳細は外部のコンポーネントに公開されない
• DevOps
  • マイクロサービスにおける組織原理

†AWSでは：運用のみのチームはない。オンコールも開発チームが請け負う

• 俊敏性

  • 狭い範囲のコンテキストで活動＝サイクルタイムが短い
  • システムもシンプル
  • パラレルな開発とデプロイが可能

• イノベーション

  • 選択に対する権限と責任を持つのでイノベーションを起こしやすい
  • DevとOpsの対立がないため、効率化やイノベーションが起こしやすい

• 拡張性

  • 適切に非干渉化されてていることで水平方向に単独にスケールできる

• 可用性

  • ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

課題

• 分散型であることは難しい
  • システム数が増える
  • 協調動作の難しさ
  • コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
  • ネットワークの信頼性は無限ではない、帯域も無限ではない
• 移行が大変
  • モノリシックなシステムの分割は難しい
• 組織
  • 組織体制の変更が必要になるが、それは大変なこと
• アーキテクチャの難易度
  • 非同期通信
  • データ整合性
  • やっぱりココが一番の課題
  • サービスディスカバリ
  • 認証
• 運用の複雑さ

アーキテクチャ

一番シンプルなパターン

CloudFront - ALB - ECS - datastore(ElastiCache, Dynamo, )
|
S3

• バックエンドをRESTfulなAPIにしたSPA
• 静的なコンテンツはS3とCloudFront
  • CDN通すことでレイテンシが上がることもある
  • キャッシュとの併用を検討
• ECSとAutoScalingをALBとともに使うことが多い
  • ALB(L7LB)でアプリレベルの情報をルーティング
  • コンテナインスタンスにリクエストを分散
  • ECSのコンテナを負荷に応じてスケールアウト／インする

コンテナのメリット

• Portable
• Flexible
• Fast
  • 軽量で早い
  • ポータビリティと関連して開発サイクルも早く

• Efficient

• 一貫性のある環境

• バージョン管理出来る

Dockerの特徴

• Package
• Ship
• Run

ECS

• 複数のコンテナをEC2のクラスタ上で一元管理
  • まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
  • EKS(Kubernetes)も発表されています

データストア

• インメモリ
  • Memcached, Redis
  • ElastiCache
  • DB負荷の軽減
• RDBMS
  • 無限のスケーリングには向いていない
  • Amazon RDS
• NoSQL
  • 水平スケーリングをサポートするものが多い
  • テーブル結合ができないのでロジックの実装が必要になる場合も
  • Amazon DynamoDb, KynamoDB Accelarator(DAX)

APIの実装

• APIの設計、改善、デプロイ、モニタリング、保守派手間がかかる
• 異なるバージョンが混在すると大変

Amazon API Gateway

• 複数バージョンとステージ
• Cognite User Poolsと連携して認証を追加
• スロットリング、モニタリング
• バックエンドとしてLambdaが使える

サーバーレス

• サーバーはないに越したことはない
• スケーリングと高可用性の担保が大変

CloudFront - API Gateway - Lambda - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

課題をAWSでどうするか

サービスディスカバリ

• お互いの死活確認や発見

• ハードコードするとスケールできない

  • メタデータをどこに置くか

• ALBを利用したサービスディスカバリ

• DNS(Route53)のサービスディスカバリ

  • VPC単位の振り分け

• ECSイベントストリームを使用したサービスディスカバリ

  • CloudWatchイベントで拾ってキック
  • LambdaでRoute53に登録
  • これが一番多いかも

• DynamoDBを使用したサービスディスカバリ

  • DNSキャッシュの問題がない
  • 自由度が高い
  • 実装が大変
  • DynamoDBストリームを活用して他のサービスへステータス変更を反映

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

  • イベントで処理する
  • いわゆる結果整合性とも関連
  • Dual Write Problem
  • Event Sourcing
    • 状態の記録ではなく状態の変更「イベント」を記録
    • Amazon Kinesis
    • kinesisにpublishして他サービスはsubscribe
    • S3にログを残す
    • トランザクションログの仕組み

モニタリング

• CloudWatch
  • ログファイルの一元化
  • CloudWatch LogsかS3に保存可能
  • ECSはCloudWatch Logsに一元化できる

分散トレース

• AWS X-Ray
• 複数サービスに分散したリクエスト処理を透過的に追える

LogWatchの先に Kinesis FireHorse - ほにゃほにゃ

スロットリング

• 大事だよ

リトライ

• 多くのエラーはリトライでカバーできるものが多い
• リトライ多発で過負荷になることがある
  • Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
  • 更に乱数でゆらぎを付けて重ならないように

LT：クラウド型医療系業務システムと Microservices への歩み by @hashedhyphen さん

クラウド型電子カルテシステムの話

• メインロジックをRails
• 常時接続をNode.js
• バックエンドをScala
• 基盤はAWS

ここに至る道のり

ファーストリリース前

• レコメンドは大量のデータが必要

• メインロジックで実現させようとすると厳しかった

  • Threadとか試したけど……
  • 別アプリケーションとして分離
  • JVM上でScala + Skinnyでスレッドアプリケーションンを実装
  • Microservicesちっくな構成へ

• 障害検知時

  • メインロジック内のプロトタイプ版が動く！

会計機能リリース前

• お金を扱う機能は安定性が欲しい
• Scala + Cats による実装を別エンドポイントとして実装
• マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

まとめ

• ちょっとマイクロサービス化したことで自由度が上がった
• 原理主義的にならなくても恩恵がある
• エンジニアの伸びしろ！

FrontEndからみるmicroserviceとBackendからみるmicroservice by @taka_ft さん

Takahiro Fujii @ Rakuten Travel

楽天内でも採用アーキテクチャはサービスによって異なる。

サービスとしては

• コンシューマ向け
• Extranet
• In-house
• other
  • ここまではWEBとモバイルがあって、100以上のAPIを利用する
• API（内部APIを直接利用）

Phase 1

• 大きなモノリシックなアプリだった
• 機能がどんどん増えていく
  • 機能別で複数のモノリシックなアプリに分割
  • その後フロントエンドとバックエンドに分割

Phase 2

• ドメインモデルを整理
• なるべくRESTfulで作るようになっていった
• 大きなAPIから小さなAPIに分離
• I/Fの決定に時間がかかるようになった
• API呼び出しが大変になった

• Microservicesっぽくなってきた 2014年くらい

• 国内予約、海外予約で多言語化だけではない商習慣に根ざしたドメインの差異による重複ロジックの増殖が起きた

• Microservicesっぽくなってきたが、どんどん品質が下がっていった

Phase 3

（ちょうど前日にプレスリリース）サイト前面刷新に向けての取り組み

• FrontendsはJavaScriptに刷新
• API GatewayにKong

組織

• フロントエンドチームが2人から始まって半年でReactエンジニアを集めて20人以上に
  • 日本人は2, 3人

UI Component

• SpringからJavaScriptでSPAに変更
• zeplinのデザインモックからUI Componentを実装するようになった
• Storyboardを使ってUI Coponentを管理
• ドメインを含むUI Componentはドメインと結び付きが強いことが多い＝専用のオーケストレーションAPIを用意してUI Componentないで処理を閉じることが出来る

• レスポンシビリティを明示的に定義

  • どこまでフロントエンドでやるか、どこからAPIからもらうか

• フロントエンドの「使いやすいレスポンス」の要求

• バックエンドの「汎用的でシンプルなレスポンス」の希望

  • これらのバランスを取る

• API Gatewayはフロントエンド（UI）チームの管轄

  • ただし状況によってはバックエンド側に持っていくことも検討するつもり

LT: "マイクロサービスはもう十分"か？ by @qsona さん

POSTDに投稿していた翻訳記事。

スタートアップ企業のほとんどはマイクロサービスをさいようすべきではない

銀の弾丸はない。

「チーム間の依存性」の解決にマイクロサービスというアプローチは違う。疎結合と分散は別。

組織が大きくなると、複数チームが1つのコードベースを触るようになる。そしてマイクロサービス化したくなる。

しかし、モノリスの分割で十分。

チームとは何か

• 自律的に動けるべき

  • チームが増えるとコミュニケーションコストや、しがらみ

• チームの分割は目的にそった分割を行う

• 悪い分割の例： Dev / Ops

• 依存度が低いほど自律的に動ける

• High Output という本

• 使命型組織／技術型組織

  • Micorservicesは使命型組織
  • 組織間が密ならサービス間も密になる

話戻して

• スタートアップは組織をキレイに分割することが難しい

• 分割しても密になってしまう

• 大きなモノリスになるとやはり分割は難しい

  • ドメインの意識は必要

• マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNCが初期からマイクロサービスでやってた理由

• 単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

---

あとで読み返して修正します。
資料パスの追加とかも。