AWS Summit Tokyo 2016 / 聴講メモ / クラウド時代のソフトウェアアーキテクチャ #AWS

■概要

クラウドと相性が良い
Hexagonal Architecture
- Port & Adapters
  - 特定のポートに届いたイベントをアダプター etc ... (ry
  - e.g.
    - DBのアダプター: モックに入れ替え容易
Microservice: 9つのポイント
- サービスを単一のアプリケーションではなく、小さなサービスの組み合わせで構築する
- 各サービスは独立、単一でデプロイと実行が可能
- 技術的な境界で分割するのではなく、ビジネスの遂行能力で分割する
- サービスとビジネスの境界を一致させる(技術の観点ではない
- サービス間のコミュニケーションは軽量な手段を利用する(REST)
Microservice: 利点
- Monolithicなシステムからの解放
- 単体でデプロイ・実行可能であるため、ここのサービスで自由にスケールすることが可能
- パラレルな開発とデプロイ
- 各サービスで独立性の高い実装が可能(言語、DBなど全てで同じものを使う必要がない。最適化すればよい(Polyglot Persistance
- サービス間は独立しているため、個々の可用性の問題が全体に影響しない
- ビジネス上の境界とより密接にアラインされる
Polyglot Persistance
- 例
  - 検索 => Elasticsearch / solr
  - ソーシャルデータ => グラフDB

Microserviceの考慮点
- 分散した複数のコンポーネントを扱うことの難しさ
- コンポーネント間のメッセージの増加によるレイテンシ増
- トランザクションの取り扱い: プロダクトが小さいフェーズはモノリシックが良いかも
- (ry
トランザクション
- MicroserviceではかくサービスがそれぞれDBを保つ
- (ry
イベントベースなアーキテクチャ
- いわゆる「結果整合性」の導入
- 各サービスは状態の変化に合わせてイベントを発行する
- (ry
Event Sourcing
- 「状態」を記録するのではく状態の変更という「イベント」を記録する
  - 「イベント」は追加のいmで普遍
- (ry
CQRS
- コマンドクエリ責務分離
  - システムの更新処理と参照処理の明確に分離
  - 更新処理 = 副作用あり、参照処理 = 副作用なし
RESTful な API
- リソース思考
  - 時間、条件によって「状態」は変わるがその意味は変わらない「東京の天気」
- URIによるリソース識別
- ステートレス
  - リクエストの全て。。
  - ハンバーガーショップの例
    - 冗長になるが、スケーラブル(店員が変わっても良い)
- HTTPメソッドによる...
HTTPステータスコード
- 意味のあるコードを必ず返す

※当日の生メモです(ほぼ校正していませんm(_ _)m
※登壇者の方の情報など一部 http://www.awssummit.tokyo/devcon/index.html から引用させて頂きました