トップ ソリューション 次世代のアプリケーション運用環境「Kubernetes」

Kubernetes保守サポート&ソリューション

次世代のアプリケーション運用環境|Kubernetes|オープンソースで実現するクラウド・ネイティブ・インフラストラクチャー

背景

近年、新しいサービスを企画してから、開発、世の中にリリースするまでに許される期間は益々短くなってきています。また、そうして新規に開発する機能は、既存の機能と適切に分離され、障害時に既存の機能に影響を与えないことと、リリース後に急なニーズの高まりに合わせて適切なコストでスケールすることが求められています。

このような要望に応えるため、「マイクロサービス・アーキテクチャ」という設計思想、並びにそれを実現する「コンテナ」と呼ばれるアプリケーションの実行環境が注目されています。また、アプリケーションを「コンテナ」として効率的に運用するためのオーケストレータとしてオープンソース製品「Kubernetes」の普及が進んでいます。

マイクロサービス・アーキテクチャとは

「マイクロサービス・アーキテクチャ」は、従来よりも細かい機能単位でアプリケーションを分割する考え方です。1つのアプリケーション/開発チームが担う役割が小さくなることで、開発スピードを上げることができ、また障害時の影響範囲を限定、スケール時のリソース使用率を下げ効率的にスケールすることなどが期待されています。
従来型の設計思想とマイクロサービスの違いは以下の図の通りです。

マイクロサービス・アーキテクチャとは1

マイクロサービスによる設計思想は、コンテナという技術によって現場での採用が加速しました。コンテナは、アプリケーション・モジュールと実行環境をセットでパッケージングする仕組みです。従来のハイパーバイザーによる仮想化と比べて、軽量なリソース分割を実現できるため、マイクロサービス・アーキテクチャのアプリケーションはこの形式でパッケージングされることが多くなっています。

マイクロサービス・アーキテクチャとは2

マイクロサービス・アーキテクチャをコンテナを用いて実装することで、以下の課題を解決できます。

解決したい課題 従来の設計思想の問題点 マイクロサービスの解決方法

開発スピードの向上

モジュールの担う機能が多く、影響調査確認範囲が広い

モジュールの担う機能が少なく、影響調査・テスト範囲が狭い

システム障害時の影響の局所化

サーバダウンにより、即時全サービス停止となる

障害時はサービス単位となり、影響を局所化

柔軟なリソーススケール

スケール時、サーバ単位となりOSのリソース使用量が非効率

スケールはサービス単位。必要な個所を増強可能

コンテナオーケストレーションツール「Kubernetes」について

機能概要

マイクロサービス・アーキテクチャを支える技術の一つがKubernetesです。2014年にGoogleよりオープンソース化され、以降Cloud Native Computing Foundation(CNCF)にてオープンソースとして発展、2018年にCNCF初の卒業プロジェクト(Graduated Project)として認定されました。Kubernetesは主に以下のような機能を提供します。

コンテナの実行・管理

コンテナ実行環境は複数台のサーバで構成されており、サーバは当然障害が発生する可能性があります。そのため、配置するコンテナは耐障害性を考慮し複数のサーバに配置する必要がありますし、サーバ、あるいはコンテナが落ちたら、他のサーバで起動し直す必要があります。Kubernetesは環境上で稼働しているコンテナの状態を監視し、コンテナ停止時には自動で生存ノードで起動し直すなど、サービス継続のための機能を提供します。

コンテナの間の通信経路の提供

コンテナで稼働する機能間はAPIで通信し、互いの機能を呼び出す必要があります。コンテナを自由にスケールするために、仮想なネットワーク環境を提供し、コンテナがどこのサーバで稼働しているかを意識せずに通信できる環境を用意します。

構成要素

Kubernetesでは管理する1つのシステム「クラスタ」と呼び、構成するサーバはマスターノードとワーカーノードの2種類に大別されます。

構成要素

マスターノード

クラスタ全体を管理し、必要なコンテナがワーカーノード上で稼働するようクラスタを管理します。

主な構成要素

主な機能 役割・説明
コントローラ 複数あるワーカーノード全体で、必要なコンテナ数が稼働するよう、内部の管理情報を更新しながらコントロールする機能です。
スケジューラ これから起動するコンテナを、適切なルールに基づいてどのワーカーノードで起動すべきかコントロールする機能です。ワーカーノード上で稼働しているコンテナを考慮した負荷分散や、耐障害性を加味した分散なども可能です。
APIサーバ クラスタの現状の稼働状況、および定義されているあるべき状態を管理します。etcdと呼ばれるストレージがあり、その情報の参照・更新をAPIとしてクラスタ内部に公開しています。

ワーカーノード

実際のアプリケーションコンテナの稼働環境となります。

主な機能 役割・説明
ノード管理 自分のノードで稼働しているコンテナを監視し、また新規コンテナを起動する必要があればそれを起動します。

構成要素間の連携

上記に記載したマスターノードとワーカーノード内の構成要素はそれぞれ以下のような形で連携しながら動作します。 一例としてコンテナ障害を検知し、代替コンテナを起動する流れは以下の通りとなります。

構成要素間の連携

障害が発生しワーカーノード上のコンテナが停止すると、ノード管理機能がマスターノードに状態の変更を通知します(図上の①)。その後、マスターノードのコントローラ機能が、代替コンテナの起動を決定、配置のための定義を作成します(図上の②)。
続いて、スケジューラ機能は作成された定義を、どこで起動するかを決定します(図上の③)。
そして最後に、ワーカーノード上の管理機能が自身でアプリケーションコンテナを起動します(図上の④)。
このように、起動したい数のコンテナを適切なノードに割り振り、起動・管理してくれるツールを「コンテナオーケストレーションツール」と呼びます。

なぜOSS版Kubernetesを導入するのか

Kubernetesを導入するとした際には様々な選択肢があります。パブリッククラウドが提供するマネージドサービスや、エンタープライズ向けにKubernetes機能を拡張したソフトウェアなどです。
マネージドサービスにより自動で運用される環境や、運用に必要な機能が豊富に用意されたソフトウェアは魅力的な一方で、自分達で基盤のバージョンアップをコントロールできなかったり、他のソフトウェアへの移行が難しくなるといったデメリットもあります。

OSS版Kubernetesを導入することで、最小限の機能から安価に始められ、自分たちでコントロール可能な基盤を手に入れることができます。

Kubernetesサポートサービスの概要

これまで説明した通り、コンテナ導入に当たっては、これまでとは異なる考え方に基づいたシステム設計が必要となります。さらに、お客様のおかれたビジネス環境によって必要とされるコンテナ環境の品質、範囲も大きく異なります。
NRIではお客様のご要望に応じて様々な支援ができるサービスをご用意しました。

①コンテナ環境の構築・導入を支援してほしい

お客様がご自身でコンテナ環境を企画・設計される場合には、NRI社内で多数の実績がある設計に基づいた設計支援サービス、およびKubernetes有資格者による技術支援サービスをご利用いただけます。

サービス名 ご提供するサービス
設計支援サービス NRI指定の設定項目について要件に基づいた設計を行い、アーキテクチャ設計としてご提供いたします。
よろず相談 Kubernetes有資格者により、設計・開発時のサポートをします。

②構築したコンテナ環境について問い合わせをしたい

既に構築されたコンテナ環境に対して、その妥当性や安全性を検証するためのアセスメントサービス、本番環境で発生した製品課題を解決するための年間サポートサービスを提供いたします。

サービス名 ご提供するサービス
アセスメント 既存KubernetesクラスタのセキュリティをCIS WorkBench に基づいて評価いたします。また、Kubernetes 構成の中でも障害多発要因である各種証明書の期限チェックなど、Kubernetes 環境のアセスメントを実施します。
年間サポート Kubernetes製品の情報提供、ログ分析などの問い合わせサポートを行います。

③コンテナ環境の構築・導入を全面的にお願いしたい

NRIがビジネス環境の分析から、必要となるコンテナ環境のご提案、設計・構築まで、全面的に支援いたします。

OpenStandiaサービス

OSS利用の課題を解決し、企業にもたらすOSSのメリットを感じて頂くためのさまざまなサポート&サービスメニューをご用意しています。

お気軽にお問い合わせください
オープンソースに関するさまざまな課題、OpenStandiaがまるごと解決します。
下記コンテンツも
あわせてご確認ください。