Container-based Application Design Reference and Practice #dockertokyo

#dockertokyo で発表したコンテナベースでのアプリケーション設計についてです。

元資料
https://docs.google.com/presentation/d/1kDdUWte7B2czfyObhEPjS6W9FSrdFQWOPHtecBxQuCc/edit?usp=sharing

Transcript

1. Container-based
   Application Design
   Reference and Practice
   2019/02/26 #dockertokyo
   Kazuki Higashiguchi (@hgsgtk)
   1
   

   View Slide

2. Container-based Application
   Design
   2
   

   View Slide

3. @hgsgtk
   Kazuki Higashiguchi
   job is … Software Engineer
   lang is ... PHP, Go ...etc
   belongs to ... BASE BANK株式会社
   (BASE株式会社の100%子会社)
   worked with …
   Docker, AWS(ECS/Fargate)
   3
   

   View Slide

4. =
   4
   BASE BANK
   Mission
   「銀行をかんたんにし、全ての人が挑戦できる世の中に」
   即座に資金調達ができる金融サービス「YELL BANK(エールバンク)」
   https://thebase.in/yellbank
   

   View Slide

5. Container-based design
   Reference and Practice
   5
   

   View Slide

6. =
   Beyond the Twelve-Factor App Principles of container-based
   application design(Redhat)
   6
   Container-based design Guide and Principle
   https://content.pivotal.io/blog/beyond-the-twelve-factor-app
   https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper
   

   View Slide

7. ２つのガイドライン・原則を
   理解・実践する
   7
   

   View Slide

8. =
   ● Pivotal社が公開しているガイドライン
   ○ https://content.pivotal.io/blog/beyond-the-t
   welve-factor-app
   ● オリジナルは、The Twelve-Factor App
   ○ https://12factor.net/
   ○ Herokuの中の人が書いたクラウドアプリケー
   ションのベストプラクティス
   ● Original 12 + New 3 = 15 principles
   ● 参考
   ○ https://speakerdeck.com/tayasu/beyond-the
   -twelve-factor-app
   8
   Beyond the twelve factor app
   

   View Slide

9. 15 factors
   ~ Beyond the twelve factor app ~
   9
   1. One codebase, one application
   2. API first
   3. Dependency management
   4. Design, build, release, and run
   5. Configuration, credentials, and code
   6. Logs
   7. Disposability
   8. Backing services
   9. Environment parity
   10. Administrative processes
   11. Port binding
   12. Stateless processes
   13. Concurrency
   14. Telemetry
   15. Authentication and authorization
   

   View Slide

10. 15 factors 抜粋
    ~ Beyond the twelve factor app ~
    10
    1. One codebase, one application
    2. API first
    3. Dependency management
    4. Design, build, release, and run
    5. Configuration, credentials, and code
    6. Logs
    7. Disposability
    8. Backing services
    9. Environment parity
    10. Administrative processes
    11. Port binding
    12. Stateless processes
    13. Concurrency
    14. Telemetry
    15. Authentication and authorization
    

    View Slide

11. =
    設定・認証情報はコードから分離
    ● バージョン管理にも含めない
    ● 環境ごと（dev, stg, prd）にグルーピングすべきではない
    ● Treat Your Apps Like Open Source
    ○ “今すぐにでもコードをオープンソース化できるか ”
    ● 設定を分離する一番の方法は環境変数への格納
    外部化された設定・認証情報
    ● YAMLファイルや、web.configといった方法は anti-patterns
    ● コードから分離されていない
    ● 推奨：クラウド利用であれば下記のようなサービス（があれば）
    ○ 構造的に管理
    ○ 安全にアプリケーションに渡すことができる
    ● 推奨：設定外部化のための製品
    ○ ex. Spring Cloud Config Server
    ○ https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html
    11
    05. CONFIGURATION, CREDENTIALS, AND CODE
    

    View Slide

12. 05. 実践例
    05. CONFIGURATION,
    CREDENTIALS, AND CODE
    12
    ● AWS ECS(Fargate)
    ● 設定情報は、Parameter Storeに格納
    ● Key Management Storeを活用して暗号化
    ● コンテナ実行時にParamter Storeから取得し
    た設定を注入
    ● https://devblog.thebase.in/entry/2019/01/16/110000
    

    View Slide

13. =
    ● ログをイベントストリームとして扱う
    ● ファイルシステムに依存しない
    ● 全てのログは、stdout・stderrに書き出す
    ● ログの集約・分析は、ElasticSearch, Logstash, Kibanaといったツールを活用す
    る
    13
    06. LOGS
    

    View Slide

14. 06. 実践例
    14
    06. LOGS
    ● アプリケーションが書き出すログは全て標準出
    力へ
    ● ECS タスクから標準出力をCloudWatchLogs
    に流れる用に設定
    ○ https://dev.classmethod.jp/cloud/aws/e
    cs-cloudwatch-logs/
    ● CloudWatchLogs → ElasticSearch&Kibana
    ○ 「ECS on Fargateで動いているプログラ
    ムのログをElasticsearch/Kibanaで可視
    化」 by @tomy103rider
    ○ https://qiita.com/tomy103rider/items/44
    1313808aa337dd4500
    

    View Slide

15. =
    ● ECS→CloudWatchLogsの際に、stdout/stderr両方同じストリームに流れる
    ● 即時ログを見る際にCloudWatchLogsを使うが、生文字列で見るのは苦痛
    ● 全てのログは統一された形式でjson文字列に整形・出力
    ● CloudWatchLogsから見る際は、awslogs・jqコマンドを利用
    ○ https://github.com/jorgebastida/awslogs
    ○ https://stedolan.github.io/jq/
    15
    +α LOGの構造化
    

    View Slide

16. =
    ● アプリケーションはコンテナ単位でサービスとして公開
    ● 公開するポートは、環境ごとに :8080, :2000と変わりうる
    ● 環境変数によって変更できるようにする
    16
    11. PORT BINDING
    

    View Slide

17. 11. 実践例
    11 PORT BINDING
    17
    ● 公開するポートは環境変数から取得する
    ● ローカル・開発・検証・本番等環境ごとに環境
    変数に対して公開ポートを設定
    

    View Slide

18. =
    ● 必要な3つの監視
    ● Application performance monitoring (APM)
    ○ パフォーマンス
    ● Domain-specific telemetry
    ○ KPI、ビジネス指標
    ● Health and system logs
    ○ 死活監視
    18
    14. TELEMETRY
    

    View Slide

19. 14. 実践例
    14 TELEMETRY
    19
    ● ヘルスチェック用のエンドポイントを用意する
    ○ HTTPサーバのみ
    ○ DBサーバ・Redisサーバへの接続も含む
    ● Mackerel を利用してエンドポイントに対して
    チェックを行う
    ○ https://mackerel.io
    

    View Slide

20. =
    ● Redhatが公開しているホワイトペーパー
    ○ https://www.redhat.com/en/resources/clou
    d-native-container-design-whitepaper
    ● コンテナベースアプリケーションの設計原
    則について
    ● The Twelve-Factor Appなどからヒントを
    得てまとめられた
    20
    Principles of container-based application design(Redhat)
    

    View Slide

21. Principles
    ~ Principles of container-based
    application design(Redhat) ~
    21
    1. SINGLE CONCERN PRINCIPLE (SCP) 単一関
    心の原則
    2. HIGH OBSERVABILITY PRINCIPLE (HOP) 高
    観測可能性の原則
    3. LIFE-CYCLE CONFORMANCE PRINCIPLE
    (LCP) ライフサイクル適合の原則
    4. IMAGE IMMUTABILITY PRINCIPLE (IIP) イ
    メージ不変性の原則
    5. PROCESS DISPOSABILITY PRINCIPLE (PDP)
    プロセス廃棄性の原則
    6. SELF-CONTAINMENT PRINCIPLE (S-CP) 自
    己完結性の原則
    7. RUNTIME CONFINEMENT PRINCIPLE (RCP)
    ランタイム制限の原則
    

    View Slide

22. Principles 抜粋
    ~ Principles of container-based
    application design(Redhat) ~
    22
    1. SINGLE CONCERN PRINCIPLE (SCP) 単一
    関心の原則
    2. HIGH OBSERVABILITY PRINCIPLE (HOP) 高
    観測可能性の原則
    3. LIFE-CYCLE CONFORMANCE PRINCIPLE
    (LCP) ライフサイクル適合の原則
    4. IMAGE IMMUTABILITY PRINCIPLE (IIP) イ
    メージ不変性の原則
    5. PROCESS DISPOSABILITY PRINCIPLE (PDP)
    プロセス廃棄性の原則
    6. SELF-CONTAINMENT PRINCIPLE (S-CP) 自
    己完結性の原則
    7. RUNTIME CONFINEMENT PRINCIPLE (RCP)
    ランタイム制限の原則
    

    View Slide

23. =
    ● Like “Single Responsibility Principle” (単一責任の原則）
    ○ “クラスはただ一つの責任をもつべきだ ”
    ● コンテナイメージの再利用・置換可能性が狙い
    ● 一つのプロセス（コンテナ）は一つの関心に対処する
    ● 複数の関心に対処する必要がある場合、サイドカーといったパターンやInit
    Containerを使用
    ○ https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
    ○ https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
    23
    SINGLE CONCERN PRINCIPLE (SCP)
    

    View Slide

24. SCP 実践例
    24
    SINGLE CONCERN PRINCIPLE
    ● API アプリケーション・mackerel-agentをサイド
    カーで動かす
    ● mackerel-container-agent
    ○ https://mackerel.io/ja/docs/entry/howto/
    container-agent
    ○ コンテナオーケストレーションプラット
    フォームを対象とした専用の監視エージェ
    ント
    

    View Slide

25. =
    ● コンテナは、アプリケーションをブラックボックスのように取扱い、統一された方
    法でパッケージ化して実行
    ● 活動状況や準備状況など、様々な状態チェックに対してAPIを提供する
    ● 重要なイベントをSTDERR・STDOUTに記録、Fluentdなどツールを活用してログ
    集約
    25
    HIGH OBSERVABILITY PRINCIPLE (HOP)
    

    View Slide

26. HOP 実践例
    26
    HIGH OBSERVABILITY
    PRINCIPLE
    ● STDOUT・STDERRにログを出力する
    ● 死活情報を取得するヘルスチェックエンドポイ
    ントの用意
    

    View Slide

27. =
    ● コンテナ化アプリケーションは不変
    ● ビルドされた後、異なる環境間で変化することは想定されていない
    ● ランタイムデータの保存は外部手段を利用
    ● 外部化した設定を環境によって使い分ける
    27
    IMAGE IMMUTABILITY PRINCIPLE (IIP)
    

    View Slide

28. IIP 実践例
    28
    IMAGE IMMUTABILITY
    PRINCIPLE
    外部化された設定情報
    ● 環境ごとに異なる設定情報は、AWS
    Parameter Storeに保存
    ランタイム情報の実行時注入
    ● コンテナ実行時に、環境変数に注入する
    

    View Slide

29. =
    ● ビルド時にコンテナは必要なすべてを含む必要がある
    ● 追加のライブラリはコンテナビルド時に追加する
    ○ ex. pythonが必要であればpythonをコンテナに含める
    ● 唯一の例外は、設定など環境に応じて異なるもの
    29
    SELF-CONTAINMENT PRINCIPLE (SCP)
    

    View Slide

30. SCP 実践例
    30
    SELF-CONTAINMENT PRINCIPLE
    https://go-talks.appspot.com/github.com/hgsgtk/gocon2018-lt/realize.s
    lide#8
    ● イメージ作成に必要なものはDockerfile内に記
    述
    

    View Slide

31. =
    1. イメージは小規模になるよう目指す
    2. 任意のユーザーIDをサポートする
    3. 重要なポートをマークする
    4. 永続データにボリュームを使用する
    5. イメージにメタデータを設定する
    6. ホストとイメージを同期させる
    31
    Redhat +α
    

    View Slide

32. Summary
    Container-based Application Design
    Reference and Practice
    32
    ● APIアプリケーションをコンテナベースで動かす
    ためにはコンテナを前提とした設計が必要。
    ● 自身のアプリケーションがガイドライン・原則を
    満たしているか改めて見直してみると理解が
    深まる
    

    View Slide