The Evolution of System Architecture

The Evolution of System Architecture

JASON #20150313

9054e8c93ca920a18b9822237c09f0a4?s=128

Hidetake Iwata

March 13, 2015
Tweet

Transcript

  1. The Evolution of System Architecture Hidetake Iwata 1

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

    価 値 リリース リリース フィードバック フィードバック リリース
  3. プロセスとアーキテクチャ 環境の変化を受け入れて、プロダクトを早くリ リースできるように進化している プロセス • Lean • Pull Request driven

    Development アーキテクチャ • Microservices • Immutable Infrastructure 3 今回のスコープ
  4. 変化に対応 & 早くリリース • 変更の粒度を小さくする • 変更の影響範囲を小さくする:疎結合 • リリースのコストを小さくする •

    小さい単位でリリースする:Microservices • 無停止でコンポーネントを交換する:Immutable 4 サービスA 変更 リリース チームA サービスB 変更 リリース チームB API
  5. Concept 小さなサービスが自律的に動作するインフラ 5 サービスA 変更 チームA Service Registry Cluster Management

    サービスB 変更 チームB Server Server Server Server
  6. Solution 流行りのツールをバンバン使っていこうぜ! 6 App PR チームA Consul Serf App PR

    チームB Docker Docker Docker Docker
  7. 7

  8. 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
  9. None
  10. Portability Scalability Operability

  11. Portability (1/3) 1. リポジトリから環境にデプロイする • アプリごとに唯一のリポジトリが存在する • アプリ間でリポジトリを共有しない • 環境ごとにリポジトリを分けない

    2. ライブラリの依存関係は宣言的に管理する • 手作業ではなくツールで管理する • 例:Rubygems, Maven, Bower 3. 環境依存の設定は環境変数で実行時に注入する 4. バックエンドサービスを交換可能にする • 例:Database, Message Queue, Memcache • バックエンドサービスの接続先は環境変数でアプリに渡す • コードを変更することなく接続先などを変更可能とする 11
  12. 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
  13. コミットに対して ビルド コミットに対して ビルド 開発環境で 実行 開発環境に リリース Portability (3/3)

    13 Repository Code Build Release Process テスト環境 で実行 テスト環境に リリース Release Process 開発環境用の設定 テスト環境用の設定 ローカルDB テストDB Code Build 依存ライブラリ 依存ライブラリ Port 8080 Port 80
  14. Scalability (1/2) 7. StatelessでShared Nothingな実行プロセス • メモリやファイルシステムは一時領域にすぎない • 永続化が必要なデータはStatefulなバックエンドサービスに格 納する

    • データベース • セッションデータはMemcacheに入れる • Sticky SessionはScalabilityを阻害 8. 高速な起動と安全なシャットダウン • 起動から数秒でリクエストを処理可能とする • リリースやスケールアップのアジリティが向上 • グレースフルシャットダウン • クラッシュに対して堅牢であること • トランザクション • ベキ等 14
  15. Scalability (2/2) 9. 複数プロセスによるスケールアウト • 複数の物理マシンに水平分割する • プロセスマネージャがプロセスを管理する • 負荷に応じて必要な種類のプロセスを増やしていく

    • 例:Web (nginx), App (node), Task Worker (java), … 15
  16. Operation: Environment Gap 10. 開発環境と本番環境を一致させる 両者のギャップを最小化する すなわち、 • 開発者が書いたコードは早くデプロイすべき •

    開発者自身がデプロイを行い、その後、本番環境の挙動をモ ニタリングすべき • 同じミドルウェアやツールを使用すべき 16 ギャップ Traditional App Twelve Factor App 時間 デプロイの間隔 数週間 数時間 人 コードを書く人と デプロイする人 異なる人 同じ人 ツール ミドルウェアやツール 異なる できるだけ一致
  17. Operation: Monitoring 11. アプリはログの送り先を意識しない • アプリは標準出力にログを書き出す • 実行環境がログの送り先を管理する 例: •

    開発環境では、コンソールに表示する • テスト環境では、ファイルに出力した上でチャットに流す • 本番環境では、ファイルに出力した上で運用監視やログ分析に 流す • ログルータが外部に転送する Fluentd • 長期保管のためのストレージ • 運用監視システム Zabbix, Munin • ログ分析システム ElasticSearch/Kibana, Redshift 17
  18. Operation: Administration Tools 12. 運用管理ツールはアプリと同様に取り扱う 例: • データベースの移行スクリプト • データベースのパッチ

    • 障害調査用のコンソール • アプリと同じ条件下で実行する • ライブラリ • 環境依存の設定 • アプリと一緒にデプロイする • バージョンを同期させるため 18
  19. まとめ 価値を継続的に向上させるには • ビジネスを取り巻く環境の変化を受け入れる • プロダクトを素早く提供する そのためには • いつでも要求を取り込んでリリースできるプロセス •

    誰でも容易に動かせるソフトウェア • 変化に柔軟に対応できるインフラ それゆえ • アーキテクチャに制約が生じる • 一つの解が The Twelve Factor App 19