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
2. Container-based Application Design 2
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
4. = 4 BASE BANK Mission 「銀行をかんたんにし、全ての人が挑戦できる世の中に」 即座に資金調達ができる金融サービス「YELL BANK(エールバンク)」 https://thebase.in/yellbank
5. Container-based design Reference and Practice 5
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
7. ２つのガイドライン・原則を 理解・実践する 7
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
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
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
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
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
13. = • ログをイベントストリームとして扱う • ファイルシステムに依存しない • 全てのログは、stdout・stderrに書き出す • ログの集約・分析は、ElasticSearch, Logstash, Kibanaといったツールを活用す る 13 06. LOGS
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
15. = • ECS→CloudWatchLogsの際に、stdout/stderr両方同じストリームに流れる • 即時ログを見る際にCloudWatchLogsを使うが、生文字列で見るのは苦痛 • 全てのログは統一された形式でjson文字列に整形・出力 • CloudWatchLogsから見る際は、awslogs・jqコマンドを利用 ◦ https://github.com/jorgebastida/awslogs ◦ https://stedolan.github.io/jq/ 15 +α LOGの構造化
16. = • アプリケーションはコンテナ単位でサービスとして公開 • 公開するポートは、環境ごとに :8080, :2000と変わりうる • 環境変数によって変更できるようにする 16 11. PORT BINDING
17. 11. 実践例 11 PORT BINDING 17 • 公開するポートは環境変数から取得する • ローカル・開発・検証・本番等環境ごとに環境 変数に対して公開ポートを設定
18. = • 必要な3つの監視 • Application performance monitoring (APM) ◦ パフォーマンス • Domain-specific telemetry ◦ KPI、ビジネス指標 • Health and system logs ◦ 死活監視 18 14. TELEMETRY
19. 14. 実践例 14 TELEMETRY 19 • ヘルスチェック用のエンドポイントを用意する ◦ HTTPサーバのみ ◦ DBサーバ・Redisサーバへの接続も含む • Mackerel を利用してエンドポイントに対して チェックを行う ◦ https://mackerel.io
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)
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) ランタイム制限の原則
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) ランタイム制限の原則
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)
24. SCP 実践例 24 SINGLE CONCERN PRINCIPLE • API アプリケーション・mackerel-agentをサイド カーで動かす • mackerel-container-agent ◦ https://mackerel.io/ja/docs/entry/howto/ container-agent ◦ コンテナオーケストレーションプラット フォームを対象とした専用の監視エージェ ント
25. = • コンテナは、アプリケーションをブラックボックスのように取扱い、統一された方 法でパッケージ化して実行 • 活動状況や準備状況など、様々な状態チェックに対してAPIを提供する • 重要なイベントをSTDERR・STDOUTに記録、Fluentdなどツールを活用してログ 集約 25 HIGH OBSERVABILITY PRINCIPLE (HOP)
26. HOP 実践例 26 HIGH OBSERVABILITY PRINCIPLE • STDOUT・STDERRにログを出力する • 死活情報を取得するヘルスチェックエンドポイ ントの用意
27. = • コンテナ化アプリケーションは不変 • ビルドされた後、異なる環境間で変化することは想定されていない • ランタイムデータの保存は外部手段を利用 • 外部化した設定を環境によって使い分ける 27 IMAGE IMMUTABILITY PRINCIPLE (IIP)
28. IIP 実践例 28 IMAGE IMMUTABILITY PRINCIPLE 外部化された設定情報 • 環境ごとに異なる設定情報は、AWS Parameter Storeに保存 ランタイム情報の実行時注入 • コンテナ実行時に、環境変数に注入する
29. = • ビルド時にコンテナは必要なすべてを含む必要がある • 追加のライブラリはコンテナビルド時に追加する ◦ ex. pythonが必要であればpythonをコンテナに含める • 唯一の例外は、設定など環境に応じて異なるもの 29 SELF-CONTAINMENT PRINCIPLE (SCP)
30. SCP 実践例 30 SELF-CONTAINMENT PRINCIPLE https://go-talks.appspot.com/github.com/hgsgtk/gocon2018-lt/realize.s lide#8 • イメージ作成に必要なものはDockerfile内に記 述
31. = 1. イメージは小規模になるよう目指す 2. 任意のユーザーIDをサポートする 3. 重要なポートをマークする 4. 永続データにボリュームを使用する 5. イメージにメタデータを設定する 6. ホストとイメージを同期させる 31 Redhat +α
32. Summary Container-based Application Design Reference and Practice 32 • APIアプリケーションをコンテナベースで動かす ためにはコンテナを前提とした設計が必要。 • 自身のアプリケーションがガイドライン・原則を 満たしているか改めて見直してみると理解が 深まる