Slide 1

Slide 1 text

コンテナ監視って何見るの? ~初心者編~ Koji Aizawa 2021/07/26 OpsJAWS

Slide 2

Slide 2 text

Agenda 1. コンテナの課題とオーケストレーションの必要性 2. 監視の基本的な考え方 a. アプローチの仕方 b. コンテナの状態変化を継続的に把握する重要性 3. まとめ

Slide 3

Slide 3 text

コンテナって何見ればいいの? コンテナって何を見ればいいの?

Slide 4

Slide 4 text

1. コンテナの課題とオーケストレーションの必 要性

Slide 5

Slide 5 text

本番環境では各コンポーネントを 冗長化するのが基本 ● コンテナの障害対策 ○ 複数台のコンテナを起動 ○ ロードバランサーでアクセス分散 ● サーバの障害対策 ○ 各コンテナは別々のサーバで起動 コンテナ単体の課題とオーケストレーションの必要性 出典:『Kubernetes on AWS』(リックテレコム刊  2020年)

Slide 6

Slide 6 text

コンテナ単体の課題とオーケストレーションの必要性 本番環境では各コンポーネントを 冗長化するのが基本 ● コンテナの障害対策 ○ 複数台のコンテナを起動 ○ ロードバランサーでアクセス分散 ● サーバの障害対策 ○ 各コンテナは別々のサーバで起動 コントロールプレーン コンテナ単体の課題とオーケストレーションの必要性 出典:『Kubernetes on AWS』(リックテレコム刊  2020年)

Slide 7

Slide 7 text

オーケストレーションサービスの構成要素 ● コントロールプレーン ノードはどれか、コンテナをどのノード に配置すべきかなどの管理を行うもの ● データプレーン コンテナを実行するサーバそのもの AWS Blog(Docker on AWS)より引用: https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/


Slide 8

Slide 8 text

オーケストレーションサービスの構成要素 コントロールプレーン データプレーン コンテナたち

Slide 9

Slide 9 text

2. 監視の基本的な考え方

Slide 10

Slide 10 text

監視の基本的な考え方 1/3   ● コントロールプレーン ノードはどれか、コンテナをどのノード に配置すべきかなどの管理を行うもの ● データプレーン コンテナを実行するサーバそのもの コントロールプレーンの監視 →マネージドなので不要 AWS Blog(Docker on AWS)より引用: https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/


Slide 11

Slide 11 text

監視の基本的な考え方 2/3   ● コントロールプレーン ノードはどれか、コンテナをどのノード に配置すべきかなどの管理を行うもの ● データプレーン コンテナを実行するサーバそのもの コントロールプレーンの監視 →マネージドなので不要 データプレーンの監視 →EC2なので今までと同じ  (Fargateなら管理から解放) AWS Blog(Docker on AWS)より引用: https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/


Slide 12

Slide 12 text

監視の基本的な考え方 3/3   ● コントロールプレーン ノードはどれか、コンテナをどのノード に配置すべきかなどの管理を行うもの ● データプレーン コンテナを実行するサーバそのもの コントロールプレーンの監視 →マネージドなので不要 データプレーンの監視 →EC2なので今までと同じ  (Fargateなら管理から解放) AWS Blog(Docker on AWS)より引用: https://aws.amazon.com/jp/blogs/news/jp-docker-on-aws-container-service-selection-example/
 コンテナの監視 ・EC2ベース(プロセス監視に近い ) ・オーケストレーションならではのコン テナ挙動を捉える

Slide 13

Slide 13 text

具体例:Amazon ECSのタスク起動フロー 1. タスク定義で指定したキャパシティ(CPU・メモリ)でノードのリソースを 確保 2. コンテナレジストリからイメージをpull 3. コンテナを起動 4. ヘルスチェック 5. ユーザーからのリクエストを受け付ける Running Pending Task Status

Slide 14

Slide 14 text

具体例:Amazon ECSのタスク起動フロー 1. タスク定義で指定したキャパシティ(CPU・メモリ)でノードのリソースを 確保 → リソースを確保できない 2. コンテナレジストリからイメージをpull → イメージをPullできない 3. コンテナを起動 → コンテナを正常に起動できない(起動処理失敗など) 4. ヘルスチェック → ヘルスチェック失敗 5. ユーザーからのリクエストを受け付ける → 高負荷などによるリソース過剰使用など Running Pending Task Status

Slide 15

Slide 15 text

具体例:この時何が起こるか? いずれもタスクの再作成(問題のタスクは停止され、新しいタスクが作成)が 繰り返される ● Pendingから停止した場合は、一定間隔で再試行&試行回数上限あり。 ● Runningから停止した場合は、無期限で再作成される ※AWS公式Docより つまり、予期しないタスクの再作成が発生する可能性がある、ということ Amazon EC2時代も、何らかのサーバー異常により Amazon EC2のTerminate・再作成がないわけ ではないが、コンテナ(=プロセス)の停止・起動の方がよりカジュアルに発生しやすいと言える コンテナの状態変化を”継続的”に把握することが重要

Slide 16

Slide 16 text

3. まとめ

Slide 17

Slide 17 text

ああ コンテナ監視のポイント コントロールプレーンの監視 マネージドサービスを使えばノータッチで OK データプレーンの監視 EC2時代と同じ コンテナの監視 EC2時代と同じ +  オーケストレーション固有の挙動(状態変化)を継 続的に捉える 本番でコンテナを使うための構成を理解する コンテナ単体の課題とオーケストレーションの必要性を 理解する ※ブログで同内容を公開中: https://blog.newrelic.co.jp/container/container-monitoring-practice/

Slide 18

Slide 18 text

2021.9.15 ¥ 3,300 (including tax) ついに発売される New Relic の全てを理解できる 330 ページにわたる技術書籍。オブザーバビリティの基本から New Relic One の基本機能、さらには16のオブザーバビリ ティ実装パターンまで含めた、初心者から応用を理解したい上 級者まで対象にした New Relic のパーフェクトガイドブック。 予約受付中 単行本版 & Kindle版 同時発売 CLICK & CHECK IT OUT!

Slide 19

Slide 19 text

Thank you @kaojiri