ITコラム

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.4

記事をシェアする:

最終回のこのページでは、クラウド・ネイティブの代表的なアプローチであるコンテナ・オーケストレーター(ここではKubernetesを例示)、モニタリングとロギングについて解説。クラウド・ネイティブについての今後の展望についても触れる。

執筆者:高良 真穂
日本IBM クラウド&コグニティブ・ソフトウェア事業本部、「15Stepで習得 Dockerから入るKubernetes」の著者

 

OpenShift/Kubernetesの導入で成果をあげる道


クラウド・ネイティブ基礎知識解説

1. CNCFとは(Vol.1)
2. クラウド・ネイティブの定義(Vol.1)
3. クラウド・ネイティブの特徴的アプローチ(Vol.2)
 3-1. コンテナ(Vol.2)
 3-2. イミュータブル・インフラストラクチャー(Vol.2)
 3-3. マイクロサービス(Vol.3)
 3-4. サービスメッシュ(Vol.3)
 3-5. 分散トレーシング(Vol.3)
 3-6. 宣言型API:declarative APIs(Vol.3)
 3-7. コンテナ・オーケストレーター Kubernetes
 3-8. モニタリングとロギング
4. クラウド・ネイティブ推進の課題と解決の取り組み
5. まとめ


3-7. コンテナ・オーケストレーター Kubernetes

ここまで挙げてきたクラウド・ネイティブな要素を実現するためのプラットフォームとして、コンテナ・オーケストレーター がある。これまでに幾つかのコンテナ・オーケストレーター が提案されてきたが、本番運用に提供可能なものは Kubernetesだけと言っても過言ではない。

コンテナ・オーケストレーター 概念図

コンテナ・オーケストレーター 概念図


 
以下にKubernetes(以下K8s)の代表的な機能を列挙する。これらの機能を基礎にして、クラウド・ネイティブなソフトウェアが動作する。

  1. 複数のコンテナを連携させる組み合わせ利用する機能
  2. 負荷に応じてコンテナ数を増減するスケールアウト機能
  3. 無停止でアプリケーションを更新するロールアウト&ロールバック機能
  4. ストレージ装置の論理ボリュームをコンテナにマウントする永続ストレージ機能
  5. 障害等によって失ったコンテナを自己修復する機能
  6. クラスタを論理的に分割して、共存環境同士が影響しない様に、リソース使用量の上限を制御する機能
  7. クラスタを構成するノード間を横断的にアクセスできるクラスタ・ネットワーク機能
  8. 稼働状態を見守るCPU使用時間、メモリ使用量、通信量などメトリックスとログの集中管理機能

CNCFがリリースするK8sは、企業が製品化する前のアップストリーム(上流)K8sと呼ばれ、最先端の機能を利用できる一方で、リリースサイクルが短く、運用には高度なスキルが要求される。これに対して、Red HatがK8sを製品化した OpenShift Container Platform(以下OCP)では次の特徴をもつ。

  • OCPでは、CICD機能とコンテナレジストリ機能が統合されている
  • 上流K8sは保守が9ヶ月で終了する。一方、OCPは長期のサポートがある
  • OCPは、Red Hat認定コンテナなど企業利用に適する脆弱性対応がある

上記の理由から、OCPは、企業利用でのK8s運用に適している。

3-8. モニタリングとロギング

クラウド・ネイティブでは、ロギングとメトリックスモニタリングは、個々のコンテナに設定するのではなく集中管理する。つまり、コンテナは、独立した仮想サーバーのように動作する。従って、これまでのように、各コンテナにログを蓄積して、個々にライフサイクルを管理することもできる。しかし、それではコンテナを維持管理する必要となるため、イミュータブル・インフラストラクチャーの利点が損なわれる。

コンテナのCPU使用時間やメモリ使用量などメトリックスは、コンテナ・オーケストレーター が単位時間あたりの統計値を持っている。そのため、メトリックス監視システムは、コンテナ・オーケストレーター を通じて情報を取得できる。

ログ管理システムがログを収集する方法として、2つのルートがある。一つ目は、ログ転送のサイドカーを利用する方式で、サイドカーは、ファイルに書き出されたログ情報をログ管理システムへ転送し、コンテナ内部にファイルが蓄積しないように処理する。二つ目は、コンテナ内部の標準出力と標準エラー出力を、コンテナ・オーケストレーター 経由でログ管理システムへ転送する方法である。

前述のどちらもアプリケーションのコンテナ上のコードに変更を加えることなく、メトリックスやログを集中管理できるため、コンテナの突然の置換えに対して情報が失われることがない。

モニタリングとログイング概念図

モニタリングとログイング概念図


 
これらモニタリング・システムを自社で運用することを望まない企業も少なくなくない。そのため、モニタリング・システムは、OSSとしてインストールするタイプ、それから、クラウドのSaaS型サービスタイプなど、複数が提供される。

メトリックスのモニタリング・システム

3つのパターンがあり、Kubernetes上にデプロイして利用、外部のサーバーにインストールして利用、KubernetesにエージェントをインストールしてSaaSを利用などがある。SaaSとして提供されるものは、メトリックスとログの処理を合わせもち、ダッシュボードも使い易く、通知までの機能を持つものがあるため、すぐに使い始めることができる。

CNCFホストのプロジェクト

  • Prometheus メトリックス データ収集と時系列管理
  • Cortex メトリックス データ収集と時系列管理

CNCF参加企業のOSS

  • Grafana グラフィカル表示
  • Kiali Istio Service Meshのための表示(Red Hat)
  • Weave Scope コンテナ連携状態などのグラフィカル表示

CNCF参加企業のクラウド型サービス

  • Sysdig メトリックス データ収集と時系列管理、および、グラフィカル表示
  • Datadog 同上

ログ管理システム

こちらも同様に3パターンがあり、やはり、SaaSが使い易いといえる。

CNCFホストのプロジェクト

  • Fluentd ログのフィルタリングと転送ツール CNCFプロジェクト

CNCF参加企業のOSS

  • Elastic サーチエンジンをログ管理システムとして利用
  • Logstash ログの転送と処理ツール
  • Grafana Loki Prometheusに似たログ管理システム

CNCF参加企業のクラウド型サービス

  • LogDNA SaaS型ログ管理サービス
  • Splunk SaaS型ログとモニタリング・サービス

4. クラウド・ネイティブ推進の課題と解決の取り組み

マイクロサービスは、今日のサービス志向アーキテクチャ(SOA)のデジャブの様だと評する声もある。もちろん、マイクロサービスは、現実的なボトムアップな展開を目指し、使用する技術も洗練されシンプルである。それでも、マイクロサービスによる利益と引き換えに、複雑性が増すことによって、運用が難しくなることは避けがたい。例えば、アプリケーションのコンテナ数を増やして水平スケールしたとしても、データベースに性能をスケールする機能が無ければ、ユーザーの要求に答えることができない。

データベースのスケール問題

データベースのスケール問題


 
前述のCNCFランドスケープには、クラウド・ネイティブ推進の課題に取り組むプロジェクトが多数登録されている。特にCNCFが支援(ホスト)するプロジェクトは、重要度の高いものが多い。注意点としては、それぞれのプロジェクトの成熟度は様々であり、ただちに、本番サービスの運用に適用できるとは限らない。また、CNCFからリリースされるオープンソースを、ユーザー企業が運用できるか、十分なスキルを保有するかなども考慮しなければならない。

CNCFの支援のもと課題解決のためのOSSプロジェクトが活動している。ここに、3つのプロジェクトの例を挙げる。

  1. Vitess KVSとMySQLを統合して、スケーリング可能なデータベースを実現する
  2. TiKV 分散トランザクション機能を持った、キー・バリュー・ストアのデータベースで、TiDBのKVSとなっている
  3. OpenEBS コンテナ接続ストレージ(CAS)のアーキテクチャを用いてスナップショットとクローン、バックアップとリストアを実現する

僅か4年のクラウド・ネイティブの取り組みは、IT業界の長い歴史から見れば、始まったばかりである。現在は黎明期であり、これからの発展と貢献を期待したい。

参考資料

5. まとめ

クラウド・ネイティブは、何かのソフトウェアを導入することで、クラウド・ネイティブになるものではなく、それに適した開発と運用の考え方、推進方法が欠かせない。そして、マイクロサービスには大きな利点と欠点があり、この欠点を補うため サービス・メッシュなどのツールや標準などの整備が進んでいる。しかし、マイクロサービス化という道は、ビジネスの課題を解決するための一つの選択肢であり、採用に当たっては適切な判断が必要であることも忘れてはいけない。

宣言的APIは、運用管理を大幅に省力化が期待でき、Kubernetesでも利用される。また、メトリックスとロギングは、従来と大きく異なり、個々のコンテナに設定しない。これにはサイドカーやコンテナ・オーケストレーター を通じて、対象のコンテナに変更を加えることなく、監視システムへ連携する。

取り巻く環境として、スマートフォン、タブレット そして、IoT などの活用は、ビジネスの駆動力となっており、アプリケーション、すなわち、情報システムには、厳しい非機能要件が提示されるようになってきた。これに対応するには、課題も少なくないがクラウド・ネイティブと共に進むことが、ベストプラクティスであると考える。

関連リンク

 

More ITコラム stories
2020年2月14日

COBOLは「古い」のか?令和の時代にCOBOLの“いま”を語る

レガシー・システムがデジタル・トランスフォーメーション(DX)の妨げになるという「2025年の崖」が、話題にな […]

さらに読む

2019年12月2日

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.2

クラウド・ネイティブ基礎知識解説の連載2回目。イミュータブル・インフラストラクチャーを取り上げる。コンテナ移行 […]

さらに読む

2019年12月2日

クラウド・ネイティブという考え方――これからのIT基礎知識 Vol.1

OpenShift/Kubernetesの導入で成果をあげる道 CNCF(Cloud Native Compu […]

さらに読む