６月３日AWS Summit Tokyo 2016に行ってきた！のつづき
【ランチセッション】クラウド時代のソフトウェアアーキテクチャ
をメモメモ
・・・なのだが、実は、このデベロッパーコンファレンスは、飛天の会場を３つにわけて、
発表者の音声は直接聞けず、（日本人なんだけど）同時通訳レシーバーで聞く形になっている。
そして、このランチセッションの時間
ＣＨ１をきくと、ソニーの人の話
ＣＨ２は、これ
ＣＨ３は、IoT プロジェクトはなぜ失敗するのか
という興味深い内容だったので、ＣＨ３とＣＨ２をザッピングしながら聞いていた。
ってことで、内容をあまりきいていない（ＣＨ３を聞いていた）ところもある。
っていうことを前提にメモメモ
Lambdaの本が出る
くらうど スケーラビリティだから実現できる
障害を堰堤としたデザイン
：
１２ファクターあっぷ
・一読すべし
コードベース
依存関係
設定
バックエンドサービス
ビルドリリース実行
プロセス
ポートバインディング
並行性
廃棄容易性
開発本番一致
ログ
管理プロセス
マイクロサービス→クラウドの力
６っかっけいといえば、ヘキサゴナルアーキテクチャ
イベントをアダプターがアプリケーションとやり取りする
アダプターがメッセージ変換
→モックによるＤＢテスト
マーティンファウラーのブログ
９つのポイント
・マイクロサービスとは小さなサービスの組み合わせ
・単一でデプロイと実行が可能
・コンウェイの法則
・サービスとビジネスの境界を一致
・ＲｅｓｔＦｕｌ
マイクロサービスの利点
・モノリシックなシステムからの解放
・自由にスケール
・パラレルな開発とデプロイ
・独立性の高い実装
・個々の可用性の問題が全体に影響しない
・ビジネス上の境界により密接に新井ん
ぽりぐろっとぱーしすたんす(Polyglot Persistance)
・各サービスごとに適切な言語とＤＢ
・例
検索
ソーシャル
Ｔｈｅ Ａｍａｚｏｎ Ｗａｙ
・昔モノリシックでした
・Two Piza Role ピザ２枚分の小さなチーム→サービスチーム
作るモノに対するすべて
ロードマップ、開発、運用、サポート
You build it you run it
DevOps
・デベロッパー、サービス、アプリ→組織と
アプリケーションの実装パターン
グレースフルデグラレーション ５００エラーを返さない
ストっろちんぐ：流量制限→ＡＰＩ Gatewayを使うと簡単にできます
フェイル サイレントリー
スタティックフォールバック：静的なコンテンツ、値返す
リトライ：一時的なものが多い
（指数関数えくすぽねんしゃるばっくおふ）、フィボナッチ数列による調整必要）
キャッシング：レイテンシの累積
サーキットブレーカー
パラレル
キューをうまく使う（スムースインターナルトラフック）
マイクロサービスの考慮点
・分散した複数コンポーネントを扱うことのむずかしさ
・コンポーネント間のコミュニケーションメッセージ増加によるレイテンシ象
・トランザクションの取り扱い
・サービスディスカバ理
・テスト複雑さ
プロダクト小さいと採算性落ちる
トランザクション
・複数のサービスに対する更新が必要な場合
・ＳｏＳＱＬだとＡＣＩＤさぽーとしていない場合も
イベントベースなアーキテクチャ
いわゆる結果整合性の導入
イベントドリブン処理：一時的な整合性の違いはあきらめましょう
さらにもう一歩
イベントソーシング
イベントだけを記録していく：イベントは追加のみであり不変
イベントのリプレイにより現在の状態を導出できる
・じゃない場合
状態更新とイベント発行２アクション
・そのとき
イベント永続化
ＣＱＲＳ：コマンドクエリ責務分離
更新と参照で明確に分離
→ドメイン駆動ででてくる
コマンドとクエリは要件が異なる
一貫性、正規化非正規化、スケーラビリティ
さて
ＡＰＩをどうするの
Ｒｅｓｔｆｕｌ
ＲＥＳＴとは
ろいフォールディング提唱
・ＵＲＩによるリソース識別
リソース名前を持つ情報：値は変わる
・ステートレス
・ＨＴＴＰメソッド
資料みてね
・ステータスコードで返す
ＡＷＳの話なし
ＡＷＳで構築
・ＡＰＩゲートウェイ＋らむだ
・・・
→いんふらはなんでもいい
要素
・自動化
・ＡＰＩ
結論
・スケーラブル
・方法論；あわせて
・マイクロサービス：オーバーヘッドと複雑さ・組織の話
【ランチセッション】クラウド時代のソフトウェアアーキテクチャ
をメモメモ
・・・なのだが、実は、このデベロッパーコンファレンスは、飛天の会場を３つにわけて、
発表者の音声は直接聞けず、（日本人なんだけど）同時通訳レシーバーで聞く形になっている。
そして、このランチセッションの時間
ＣＨ１をきくと、ソニーの人の話
ＣＨ２は、これ
ＣＨ３は、IoT プロジェクトはなぜ失敗するのか
という興味深い内容だったので、ＣＨ３とＣＨ２をザッピングしながら聞いていた。
ってことで、内容をあまりきいていない（ＣＨ３を聞いていた）ところもある。
っていうことを前提にメモメモ
Lambdaの本が出る
くらうど スケーラビリティだから実現できる
障害を堰堤としたデザイン
：
１２ファクターあっぷ
・一読すべし
コードベース
依存関係
設定
バックエンドサービス
ビルドリリース実行
プロセス
ポートバインディング
並行性
廃棄容易性
開発本番一致
ログ
管理プロセス
マイクロサービス→クラウドの力
６っかっけいといえば、ヘキサゴナルアーキテクチャ
イベントをアダプターがアプリケーションとやり取りする
アダプターがメッセージ変換
→モックによるＤＢテスト
マーティンファウラーのブログ
９つのポイント
・マイクロサービスとは小さなサービスの組み合わせ
・単一でデプロイと実行が可能
・コンウェイの法則
・サービスとビジネスの境界を一致
・ＲｅｓｔＦｕｌ
マイクロサービスの利点
・モノリシックなシステムからの解放
・自由にスケール
・パラレルな開発とデプロイ
・独立性の高い実装
・個々の可用性の問題が全体に影響しない
・ビジネス上の境界により密接に新井ん
ぽりぐろっとぱーしすたんす(Polyglot Persistance)
・各サービスごとに適切な言語とＤＢ
・例
検索
ソーシャル
Ｔｈｅ Ａｍａｚｏｎ Ｗａｙ
・昔モノリシックでした
・Two Piza Role ピザ２枚分の小さなチーム→サービスチーム
作るモノに対するすべて
ロードマップ、開発、運用、サポート
You build it you run it
DevOps
・デベロッパー、サービス、アプリ→組織と
アプリケーションの実装パターン
グレースフルデグラレーション ５００エラーを返さない
ストっろちんぐ：流量制限→ＡＰＩ Gatewayを使うと簡単にできます
フェイル サイレントリー
スタティックフォールバック：静的なコンテンツ、値返す
リトライ：一時的なものが多い
（指数関数えくすぽねんしゃるばっくおふ）、フィボナッチ数列による調整必要）
キャッシング：レイテンシの累積
サーキットブレーカー
パラレル
キューをうまく使う（スムースインターナルトラフック）
マイクロサービスの考慮点
・分散した複数コンポーネントを扱うことのむずかしさ
・コンポーネント間のコミュニケーションメッセージ増加によるレイテンシ象
・トランザクションの取り扱い
・サービスディスカバ理
・テスト複雑さ
プロダクト小さいと採算性落ちる
トランザクション
・複数のサービスに対する更新が必要な場合
・ＳｏＳＱＬだとＡＣＩＤさぽーとしていない場合も
イベントベースなアーキテクチャ
いわゆる結果整合性の導入
イベントドリブン処理：一時的な整合性の違いはあきらめましょう
さらにもう一歩
イベントソーシング
イベントだけを記録していく：イベントは追加のみであり不変
イベントのリプレイにより現在の状態を導出できる
・じゃない場合
状態更新とイベント発行２アクション
・そのとき
イベント永続化
ＣＱＲＳ：コマンドクエリ責務分離
更新と参照で明確に分離
→ドメイン駆動ででてくる
コマンドとクエリは要件が異なる
一貫性、正規化非正規化、スケーラビリティ
さて
ＡＰＩをどうするの
Ｒｅｓｔｆｕｌ
ＲＥＳＴとは
ろいフォールディング提唱
・ＵＲＩによるリソース識別
リソース名前を持つ情報：値は変わる
・ステートレス
・ＨＴＴＰメソッド
資料みてね
・ステータスコードで返す
ＡＷＳの話なし
ＡＷＳで構築
・ＡＰＩゲートウェイ＋らむだ
・・・
→いんふらはなんでもいい
要素
・自動化
・ＡＰＩ
結論
・スケーラブル
・方法論；あわせて
・マイクロサービス：オーバーヘッドと複雑さ・組織の話