Container-based

Application Design

Reference and Practice

2019/02/26 #dockertokyo

Kazuki Higashiguchi (@hgsgtk)

1

Container-based Application Design

2

@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

BASE BANK

Mission

「銀行をかんたんにし、全ての人が挑戦できる世の中に」

​

即座に資金調達ができる金融サービス「YELL BANK(エールバンク)」

4

https://thebase.in/yellbank

​

=

Container-based design

Reference and Practice

5

Container-based design Guide and Principle

Beyond the Twelve-Factor App

Principles of container-based application design(Redhat)

6

https://content.pivotal.io/blog/beyond-the-twelve-factor-app

https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper

​

​

=

２つのガイドライン・原則を

理解・実践する

7

Beyond the twelve factor app

• Pivotal社が公開しているガイドライン
• https://content.pivotal.io/blog/beyond-the-twelve-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

=

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

15 factors 抜粋

~ Beyond the twelve factor app ~

10

• One codebase, one application
• API first
• Dependency management
• Design, build, release, and run
• Configuration, credentials, and code
• Logs
• Disposability
• Backing services
• Environment parity
• Administrative processes
• Port binding
• Stateless processes
• Concurrency
• Telemetry
• Authentication and authorization

05. CONFIGURATION, CREDENTIALS, AND CODE

設定・認証情報はコードから分離

• バージョン管理にも含めない
• 環境ごと（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. 実践例

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

06. LOGS

• ログをイベントストリームとして扱う

​

• ファイルシステムに依存しない

​

• 全てのログは、stdout・stderrに書き出す

​

• ログの集約・分析は、ElasticSearch, Logstash, Kibanaといったツールを活用する

13

=

06. 実践例

06. LOGS

14

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

​

+α LOGの構造化

• ECS→CloudWatchLogsの際に、stdout/stderr両方同じストリームに流れる

​

• 即時ログを見る際にCloudWatchLogsを使うが、生文字列で見るのは苦痛

​

• 全てのログは統一された形式でjson文字列に整形・出力

​

• CloudWatchLogsから見る際は、awslogs・jqコマンドを利用
• https://github.com/jorgebastida/awslogs
• https://stedolan.github.io/jq/

​

15

=

11. PORT BINDING

• アプリケーションはコンテナ単位でサービスとして公開

​

• 公開するポートは、環境ごとに :8080, :2000と変わりうる

​

• 環境変数によって変更できるようにする

16

=

11. 実践例

11 PORT BINDING

17

• 公開するポートは環境変数から取得する

​

• ローカル・開発・検証・本番等環境ごとに環境変数に対して公開ポートを設定

14. TELEMETRY

• 必要な3つの監視

​

• Application performance monitoring (APM)
• パフォーマンス

​

• Domain-specific telemetry
• KPI、ビジネス指標

​

• Health and system logs
• 死活監視

​

18

=

14. 実践例

14 TELEMETRY

19

• ヘルスチェック用のエンドポイントを用意する
• HTTPサーバのみ
• DBサーバ・Redisサーバへの接続も含む

​

• Mackerel を利用してエンドポイントに対してチェックを行う
• https://mackerel.io

​

Principles of container-based application design(Redhat)

• Redhatが公開しているホワイトペーパー
• https://www.redhat.com/en/resources/cloud-native-container-design-whitepaper

​

• コンテナベースアプリケーションの設計原則について

​

• The Twelve-Factor Appなどからヒントを得てまとめられた

20

=

Principles

~ Principles of container-based application design(Redhat) ~

21

• SINGLE CONCERN PRINCIPLE (SCP) 単一関心の原則
• HIGH OBSERVABILITY PRINCIPLE (HOP) 高観測可能性の原則
• LIFE-CYCLE CONFORMANCE PRINCIPLE (LCP) ライフサイクル適合の原則
• IMAGE IMMUTABILITY PRINCIPLE (IIP) イメージ不変性の原則
• PROCESS DISPOSABILITY PRINCIPLE (PDP) プロセス廃棄性の原則
• SELF-CONTAINMENT PRINCIPLE (S-CP) 自己完結性の原則
• RUNTIME CONFINEMENT PRINCIPLE (RCP) ランタイム制限の原則

Principles 抜粋

~ Principles of container-based application design(Redhat) ~

22

• SINGLE CONCERN PRINCIPLE (SCP) 単一関心の原則
• HIGH OBSERVABILITY PRINCIPLE (HOP) 高観測可能性の原則
• LIFE-CYCLE CONFORMANCE PRINCIPLE (LCP) ライフサイクル適合の原則
• IMAGE IMMUTABILITY PRINCIPLE (IIP) イメージ不変性の原則
• PROCESS DISPOSABILITY PRINCIPLE (PDP) プロセス廃棄性の原則
• SELF-CONTAINMENT PRINCIPLE (S-CP) 自己完結性の原則
• RUNTIME CONFINEMENT PRINCIPLE (RCP) ランタイム制限の原則

SINGLE CONCERN PRINCIPLE (SCP)

• 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

=

SCP 実践例

SINGLE CONCERN PRINCIPLE

24

• API アプリケーション・mackerel-agentをサイドカーで動かす

​

• mackerel-container-agent
• https://mackerel.io/ja/docs/entry/howto/container-agent
• コンテナオーケストレーションプラットフォームを対象とした専用の監視エージェント

HIGH OBSERVABILITY PRINCIPLE (HOP)

• コンテナは、アプリケーションをブラックボックスのように取扱い、統一された方法でパッケージ化して実行

​

• 活動状況や準備状況など、様々な状態チェックに対してAPIを提供する

​

• 重要なイベントをSTDERR・STDOUTに記録、Fluentdなどツールを活用してログ集約

25

=

HOP 実践例

HIGH OBSERVABILITY PRINCIPLE

26

• STDOUT・STDERRにログを出力する

​

• 死活情報を取得するヘルスチェックエンドポイントの用意

IMAGE IMMUTABILITY PRINCIPLE (IIP)

• コンテナ化アプリケーションは不変

​

• ビルドされた後、異なる環境間で変化することは想定されていない

​

• ランタイムデータの保存は外部手段を利用

​

• 外部化した設定を環境によって使い分ける

27

=

IIP 実践例

IMAGE IMMUTABILITY PRINCIPLE

28

外部化された設定情報

• 環境ごとに異なる設定情報は、AWS Parameter Storeに保存

​

ランタイム情報の実行時注入

• コンテナ実行時に、環境変数に注入する

SELF-CONTAINMENT PRINCIPLE (SCP)

• ビルド時にコンテナは必要なすべてを含む必要がある

​

• 追加のライブラリはコンテナビルド時に追加する
• ex. pythonが必要であればpythonをコンテナに含める

​

• 唯一の例外は、設定など環境に応じて異なるもの

29

=

SCP 実践例

SELF-CONTAINMENT PRINCIPLE

30

https://go-talks.appspot.com/github.com/hgsgtk/gocon2018-lt/realize.slide#8

​

• イメージ作成に必要なものはDockerfile内に記述

Redhat +α

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

31

=

Summary

Container-based Application Design Reference and Practice

​

​

32

• APIアプリケーションをコンテナベースで動かすためにはコンテナを前提とした設計が必要。

​

• 自身のアプリケーションがガイドライン・原則を満たしているか改めて見直してみると理解が深まる

​