何でも屋エンジニアのブログ

ソフトウェア関連技術、コミュニティ、日々の雑貨

レポート: 【ランチセッション】クラウド時代のソフトウェアアーキテクチャ

技術

登壇者

西谷 圭介様（アマゾン ウェブ サービス ジャパン株式会社 技術本部 ソリューションアーキテクト）

The Twelve-Factor App

12factor.net

codebase

  • バージョン管理は当たり前、1つのコードベースから複数のアプリができるのは良くない

依存関係

  • 環境に依存しないこと
  • 依存関係を明示的に分離

設定

並行性

  • スケールするときはプロセスごと増やす

マイクロサービス

hexagonal architecture

  • 特定ポートに届いたイベントをアダプターがアプリに渡す
  • アダプターがメッセージのやり取りをする

ヘキサゴナルアーキテクチャ日本語翻訳ページ http://blog.tai2.net/hexagonal_architexture.html

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

  • 各サービスは独立、単一でデプロイと実行が可能
  • 分割単位はビジネスの境界やビジネスの遂行能力で分割する（技術的なものではない）
  • プロトコルはhttpでRESTfulのケースが多い
  • 各サービスごとにスケーリングできる

Polyglot Persistence

  • 各サービスごとに最適な言語とDBを組み合わせる
    • 検索: elasticsearch
    • ソーシャルデータ: Neo4J（グラフDB）
    • ユーザーセッション: Redis

Amazonの例

  • Amazonも昔はモノリシックなサービスだった
  • チームの体制がTwo Pizza Team理論に即した体制に変化
  • それによりチームの体制がマイクロサービスの文脈へ
  • 開発チームは小さく、それぞれのチームが開発した単位でリリースできる

www.lifehacker.jp

アプリケーションの実装パターン

Graceful Degradation

  • 500エラーは返さない
  • 一部にエラーがあっても全体の停止を起こさずその他の機能は有効に動くようにする
  • 例えば、ECサイトのリコメンド機能がダメな場合でも、トップページにアクセスしてもページが表示されるようにする。おすすめ品が表示されなくても、全部表示されないよりマシ。

Fail Silently

  • 外部向けには、エラーコードを返さない。
  • 内部できちんとロギング、監視すること。

retry

  • 失敗は一時的なものが多く、リトライすることで成功することが多いため、リトライする処理を入れる。
  • 間隔の調整はフィボナッチ数列、exponetial back offを利用する。

curcuit breaker

  • リトライの閾値を設定し、超えたときにフォールバックプランを実行する。
  • サイト全体のアベイラビリティの方が大事。

Smooth internal traffic

マイクロサービスの考慮点

トランザクション

  • 複数DBでデータが同期されている必要性
  • 結果整合性の導入
  • 状態変化に合わせてイベントを発行する
  • イベントをsubscribeし、イベントドリブンに処理を行う
  • 一時的なconsistencyの妥協

イベントソーシング

  • 状態でなくイベントを追加するという考え方
  • イベントのリプライにより現在の状態を導出できる
  • スケールしやすい（キャッシュが楽）
  • イベントドリブンでは、状態を変更しイベントを追加するが、これはイベント追加のワンアクションで済む

CQRS

  • DDDの文脈で登場
  • 更新処理と参照処理の分離
    • 更新処理は正規化、クエリは非正規化の方がいいなど差異が大きいため

RESTfulAPI

ステートレスは他の店員になっても問題無し→スケーラビリティが高い

AWSでどうマイクロサービスを実現するか

  • 満たすべき要件は自動化と自動化のためのAPI
  • インフラは何でも良い

感想

アプリケーションの実装パターンやイベントソーシングという考え方など、知らないことが多く非常に勉強になりました。
昨日からAWS Summitに参加しマイクロサービスのセッションを拝聴していて、マイクロサービスの難しい点として「分散したコンポーネントを扱う難しさ」が共通して上がっていました。また、本セッションで挙げられたトランザクションやデータ同期も確かに悩ましい問題で、西谷さんが個人的には「プロダクトが小さい場合はマイクロサービスのデメリットの方が目立つ」とおっしゃっていた理由もよくわかる気がします。ビズリーチさんのマイクロサービスに関するインタビューでも竹添さんが同じようなことをおっしゃっていました。

開発のときのオーバヘッドや、インフラコストで見ると、短期的にはデメリットのほうが大きいと思っています。どこかで損益分岐点はあると思うんですが。とりあえずスモール仕立てでやってみようとか、成功するかまったくわから状況なら、モノリシックで作って、後から大きくなったタイミングでマイクロサービスにしてもいいのではないでしょうか。

非常にためになるお話をありがとうございました！

参考

html5experts.jp 12factor.net ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳) AWS Summit Tokyo 2016 Developers Conference（DevCon） - アプリ開発・IoT の最新トレンドが集う2日間 - 2016年6月2～3日 グランドプリンスホテル新高輪 飛天会場にて開催

米AmazonのCEOジェフ・ベゾスが提唱する「2枚のピザ理論」 ｜ ライフハッカー［日本版］