The Evolution of System Architecture

JASON #20150313

Transcript

1. The Evolution of
   System Architecture
   Hidetake Iwata
   1
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. View Slide

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
   

   View Slide

9. View Slide

10. Portability
    Scalability
    Operability
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide