Online Seminar Review

コンテナSummit 2022

DX開発・運用迅速化する必須技術

New Relic

コンテナを拒絶しない!要点押さえ、活用の第一歩を

一見、未知で難解なために、二の足を踏まれるコンテナ活用。実際、漫然と進めては運用に多大な負荷が発生してしまう。コンテナ環境では複数のサーバーとコンテナが連携しているために、システム運用における監視が複雑化することが要因の1つだ。しかし解決策はある。ヒントは「オーケストレーション」だ。

常に変化し、かつ増加する厄介なシステム監視対象

New Relic Senior Solutions Consultant 会澤 康二 氏

New Relic

Senior Solutions Consultant

会澤 康二

New Relicの会澤氏が講演の最初のテーマに挙げたのは、「コンテナが求められる時代背景」だ。ひと昔前のシステムでは業務効率化を実現するために構築されていた。手紙がメールに代わり、これまで口頭でなされてきたやり取りは、その内容を電子データで記録できるようになった。そこから時代が進み、今ではクラウドを活用してIoTセンサーで情報収集、さらにそのデータはAIが自動分析する。こうしてシステムがユーザーに価値を提供するとともに、自社の経営戦略にも活用するケースが増えてきている。さらに会澤氏は「昨今は事業創造に近いところにもデジタルが活用され始めていることから、コンテナに注目が集まっています」と付け加えた。

企業がシステムに求める要件も、安定稼働だけではない。顧客に価値を提供するための新機能の追加や改善を、容易に行える技術を利用したいなど、今やそれは多種多様だ。会澤氏はこういった状況を捉え、「機能を分離・独立させる、マイクロサービスのような設計思想を用いた技術が台頭している」と分析する。

こうした時代背景と基盤技術の進化は、システム監視の側面からも変化しているという。メインフレーム上の大きなアプリケーションは、1回起動させれば安定して動き続ける。ところが、世界中の人々にデジタルビジネスを提供するためのシステム活用では、アプリケーションや各種コンポーネントは新機能の更新や、パフォーマンスの改善によって追加更新の繰り返しが当たり前。会澤氏はこれを踏まえ、コンテナ環境でのシステムの監視において「マイクロサービスの提供によって監視の対象が増え、かつその対象が常に変化することが当たり前の環境で運用しなければなりません」と、その課題を提示する。

コンテナ監視に潜む落とし穴を回避せよ

次に会澤氏は、「コンテナと仮想マシンの違い」について説明。コンテナはシステム運用を効率化するため、必要最低限のミドルウエアやフレームワーク、アプリケーションだけをプロセスとして動かしている。そこが、マシンレベルでの情報のやり取りのために、I/Oまできちんとエミュレートされている仮想マシンとは大きく異なっているという。

また、コンテナはあくまでもサーバー上のプロセスの1つ。そのため障害でサーバー自体が落ちると、コンテナも同様にすべて落ちてしまうため、本番環境では複数台のサーバー上に複数個のコンテナを分散して配置するよう設計することになる。これに対し会澤氏は次のように指摘する。

「その結果、様々なサブシステムのコンテナが存在することになります。それらのコンテナが複数のサーバー上で分散されて動くので、どこのサーバー上に動いているどのコンテナが、どのサブシステムに該当するものなのかを把握し続けることが、大きな負荷になってしまいます」

ここから会澤氏が説明につなげるのは、こうした課題を解決する「オーケストレーション」の必要性だ。オーケストレーションとは、コンテナやサーバーの冗長性を考慮しながら可用性を担保し、負荷分散や認証、セキュリティー、アクセス制御に関してもガバナンス統制が可能なコンテナを、最適に配置するツールを指す。会澤氏いわく、その筆頭ツールが「Kubernetes」であるという。その導入メリットとして、どこにデプロイしても同じアプリケーションを実行できると説明。

「アプリケーションをデプロイするには、どのくらいのスペックのコンテナを何個動かすかといった最低限のインフラ定義をコンフィグに書き込むだけで、簡単にアプリケーションをデプロイできます」(会澤氏)

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

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

コンテナ環境では複数のコンテナを複数のサーバーで運用するため、それらを管理するオーケストレーションが必要になる

画像を拡大する

システム安定稼働に向け押さえるべきは3点

ここで会澤氏は、システム環境におけるコンテナのコンポーネントを貨物船に例える。積み荷となるコンテナを載せた船が、システム環境での「データプレーン」なら、どの船にどのコンテナをどこに配置するのかを指示する役割を持つものが「コントロールプレーン」だ。まさに船に積んだコンテナを安定させて運搬するように、システムを安定稼働させるには、次の3つのポイントを意識すべきであると会澤氏はアドバイスする。

最初のポイントは「コントロールプレーンの監視」だ。「マネージドサービスの普及によって、コントロールプレーンの監視が不要となるケースが多くなってきました」(会澤氏)。2つ目のポイント「データプレーンの監視」については、「実態としてはサーバーの集合なので、今までと同じようにノード単体ではなく、システム全体としてキャパシティに対する利用状況を把握する必要がある」と続ける。そして3つ目、「コンテナの監視」に関しては次のように説明する。

「コンテナの実態はプロセスそのものです。インフラ監視の観点でいえば、プロセス監視でやるべきことに近くなります。従ってコンテナ監視の基本は、プロセスがいくつ起動されているべきか、そのプロセスが最低限必要なリソースの使用量はどれくらいで、最大どこまでリソースが使えるのかを見ていくことです」

さらに会澤氏は、オーケストレーションとしてのKubernetesが持つ「自己修復機能」について触れる。「軽微な障害は自動的に修復してくれるので、アラートが上がってきたときに、それがKubernetes自身で解決できない問題なのかどうかを、いかに早く、正確に検知するかが大切になってきます」。またアプリケーションチームによって自由にコンテナをデプロイできるようになると、様々なコンテナが乱立してクラスタの挙動が不安定になるケースが増えてくるという。会澤氏はそうした事態にも備え「クラスタ管理者はリソースが枯渇しないよう、全体のキャパシティの利用状況を把握することが大切です」とアドバイスする。

講演ではキャパシティの利用状況とコンテナの状態変化を把握するときのポイントが、例を挙げて紹介された(下図参照)。「こういうポイントを見ていくことで、クラスタの管理者としては、大きな事故もなくコンテナ環境をスタートできるケースが多くなっています。見慣れない技術だからといってコンテナを拒絶するのではなく、ポイントを押さえ、活用の一歩を安全に踏み出してもらえればと思います」と会澤氏は最後に述べ、講演を終えた。

Kubernetes安定稼働のための見るべきポイント

Kubernetes安定稼働のための見るべきポイント

Kubernetesを安定稼働させるためには、「コントロールプレーン」「データプレーン」「コンテナ」の監視がポイントとなる

画像を拡大する

このページのトップに戻る