The Evolution of System Architecture Hidetake Iwata 1

背景 ビジネスを取り巻く環境の変化にITシステムを 同期させることが求められている 価値を継続的に向上させるには • 変化を受け入れる • プロダクトを早くリリースする 2 時間 価 値 リリース リリース フィードバック フィードバック リリース

プロセスとアーキテクチャ 環境の変化を受け入れて、プロダクトを早くリ リースできるように進化している プロセス • Lean • Pull Request driven Development アーキテクチャ • Microservices • Immutable Infrastructure 3 今回のスコープ

変化に対応 & 早くリリース • 変更の粒度を小さくする • 変更の影響範囲を小さくする：疎結合 • リリースのコストを小さくする • 小さい単位でリリースする：Microservices • 無停止でコンポーネントを交換する：Immutable 4 サービスA 変更 リリース チームA サービスB 変更 リリース チームB API

Concept 小さなサービスが自律的に動作するインフラ 5 サービスA 変更 チームA Service Registry Cluster Management サービスB 変更 チームB Server Server Server Server

Solution 流行りのツールをバンバン使っていこうぜ！ 6 App PR チームA Consul Serf App PR チームB Docker Docker Docker Docker

7

The Twelve Factor App • Best Practice of Modern Web Application • Minimize time and cost for new developers • Maximum portability between execution environments • Continuous deployment for maximum agility • Scale up without significant changes to architecture • 2011年11月にAdam Wigginsが発表した （当時のHeroku Co-Founder and CTO） 12factor.net • 2013年8月に日本語訳が公開された twelve-factor-ja.herokuapp.com 8

No content

Portability Scalability Operability

Portability (1/3) 1. リポジトリから環境にデプロイする • アプリごとに唯一のリポジトリが存在する • アプリ間でリポジトリを共有しない • 環境ごとにリポジトリを分けない 2. ライブラリの依存関係は宣言的に管理する • 手作業ではなくツールで管理する • 例：Rubygems, Maven, Bower 3. 環境依存の設定は環境変数で実行時に注入する 4. バックエンドサービスを交換可能にする • 例：Database, Message Queue, Memcache • バックエンドサービスの接続先は環境変数でアプリに渡す • コードを変更することなく接続先などを変更可能とする 11

Portability (2/3) 5. アプリ自身がポートを公開する • 例：Embedded Jetty, Thin, Express • サーバコンテナは使わない • アプリは他のアプリのバックエンドサービスになれる 6. Build, Release and Run Stage • 3つのステージを厳密に分離する • 変更は必ず後続のステージに向かって伝搬する • すなわち、リリース済みのコードを変更しない 12 Run Stage Release Stage Build Stage Repository Code Build Release Process

コミットに対して ビルド コミットに対して ビルド 開発環境で 実行 開発環境に リリース Portability (3/3) 13 Repository Code Build Release Process テスト環境 で実行 テスト環境に リリース Release Process 開発環境用の設定 テスト環境用の設定 ローカルDB テストDB Code Build 依存ライブラリ 依存ライブラリ Port 8080 Port 80

Scalability (1/2) 7. StatelessでShared Nothingな実行プロセス • メモリやファイルシステムは一時領域にすぎない • 永続化が必要なデータはStatefulなバックエンドサービスに格 納する • データベース • セッションデータはMemcacheに入れる • Sticky SessionはScalabilityを阻害 8. 高速な起動と安全なシャットダウン • 起動から数秒でリクエストを処理可能とする • リリースやスケールアップのアジリティが向上 • グレースフルシャットダウン • クラッシュに対して堅牢であること • トランザクション • ベキ等 14

Scalability (2/2) 9. 複数プロセスによるスケールアウト • 複数の物理マシンに水平分割する • プロセスマネージャがプロセスを管理する • 負荷に応じて必要な種類のプロセスを増やしていく • 例：Web (nginx), App (node), Task Worker (java), … 15

Operation: Environment Gap 10. 開発環境と本番環境を一致させる 両者のギャップを最小化する すなわち、 • 開発者が書いたコードは早くデプロイすべき • 開発者自身がデプロイを行い、その後、本番環境の挙動をモ ニタリングすべき • 同じミドルウェアやツールを使用すべき 16 ギャップ Traditional App Twelve Factor App 時間 デプロイの間隔 数週間 数時間 人 コードを書く人と デプロイする人 異なる人 同じ人 ツール ミドルウェアやツール 異なる できるだけ一致

Operation: Monitoring 11. アプリはログの送り先を意識しない • アプリは標準出力にログを書き出す • 実行環境がログの送り先を管理する 例： • 開発環境では、コンソールに表示する • テスト環境では、ファイルに出力した上でチャットに流す • 本番環境では、ファイルに出力した上で運用監視やログ分析に 流す • ログルータが外部に転送する Fluentd • 長期保管のためのストレージ • 運用監視システム Zabbix, Munin • ログ分析システム ElasticSearch/Kibana, Redshift 17

Operation: Administration Tools 12. 運用管理ツールはアプリと同様に取り扱う 例： • データベースの移行スクリプト • データベースのパッチ • 障害調査用のコンソール • アプリと同じ条件下で実行する • ライブラリ • 環境依存の設定 • アプリと一緒にデプロイする • バージョンを同期させるため 18

まとめ 価値を継続的に向上させるには • ビジネスを取り巻く環境の変化を受け入れる • プロダクトを素早く提供する そのためには • いつでも要求を取り込んでリリースできるプロセス • 誰でも容易に動かせるソフトウェア • 変化に柔軟に対応できるインフラ それゆえ • アーキテクチャに制約が生じる • 一つの解が The Twelve Factor App 19