Upgrade to Pro — share decks privately, control downloads, hide ads and more …

The Evolution of System Architecture

The Evolution of System Architecture

JASON #20150313

Hidetake Iwata

March 13, 2015
Tweet

More Decks by Hidetake Iwata

Other Decks in Technology

Transcript

  1. 変化に対応 & 早くリリース • 変更の粒度を小さくする • 変更の影響範囲を小さくする:疎結合 • リリースのコストを小さくする •

    小さい単位でリリースする:Microservices • 無停止でコンポーネントを交換する:Immutable 4 サービスA 変更 リリース チームA サービスB 変更 リリース チームB API
  2. 7

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

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

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

    • データベース • セッションデータはMemcacheに入れる • Sticky SessionはScalabilityを阻害 8. 高速な起動と安全なシャットダウン • 起動から数秒でリクエストを処理可能とする • リリースやスケールアップのアジリティが向上 • グレースフルシャットダウン • クラッシュに対して堅牢であること • トランザクション • ベキ等 14
  8. Operation: Environment Gap 10. 開発環境と本番環境を一致させる 両者のギャップを最小化する すなわち、 • 開発者が書いたコードは早くデプロイすべき •

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

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

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

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