なぜKubernetesを採用するのか 2000人の開発者に提供するサービスで得られた知見と課題：巨大SIerのコンテナ・Kubernetes活用事例（3）

NRIのコンテナ・Kubernetes活用事例を紹介する本連載。第3回は開発者のQCD（Quality、Cost、Delivery）を向上させることを目的とした開発支援サービスにKubernetesを適用した事例を紹介する。

[海内映吾, 小林隆浩，野村総合研究所]

Kubernetes採用の背景とメリット

　野村総合研究所（以後、NRI）では、ここ数年でKubernetesを利用するプロジェクトが増えてきた。本記事で取り上げる自社サービス「aslead」や、社内のプライベートクラウドに構築した「OpenShift」でもKubernetesを活用している。Amazon Web Services（AWS）が提供する「Amazon EKS（Amazon Elastic Kubernetes Service）」（以後、EKS）を本番環境としてアプリケーションをデプロイしているプロジェクトも存在する。

　Kubernetes採用の背景は2つある。一つはコンテナ実行が可能なインフラを構築することでアプリケーション開発やテストをするための環境をすぐに提供できるようにすること。もう一つは、アプリケーションをコンテナ化することで、インフラストラクチャのEOL（End Of Life）に伴うアップデートをアプリケーションに影響を与えることなく実現可能にすることだ。

　コンテナの可搬性は、アプリケーションのデプロイ頻度を高めるCI（継続的インテグレーション）／CD（継続的デリバリー）との親和性が高い。Kubernetesを導入したプロジェクトが増えるにつれ、Kubernetesリソースを手軽にデプロイしたりテストしたりするためのCI/CDの需要も高まりつつある。

　NRI内のプロジェクトでは本番環境とCI環境を別にする要件が多く、EKSの場合はNRI内のセキュリティポリシーに準拠しつつ手軽にCIを実行可能な環境を用意することにしていた。その結果、Kubernetesのプロジェクト導入事例が増えるとともに、Kubernetesリソースをデプロイして手軽にテストするためのCI環境の需要が高まっていった。

社内向け開発支援ツールの提供

　NRIは2018年から社内向けの生産性向上サービスとしてコミュニケーションツールやファイル共有ツールなどを提供するasleadを内製している。利用者は独自で環境構築をする必要がなく、サービスによってセキュリティが担保される。asleadの中でも開発を支援する「aslead DevOps」は2020年10月時点で利用者が2000人を超えている。

aslead DevOpsとは

　NRIの開発現場から生まれた開発管理製品。ソースコードを管理する「GitLab」や資材を管理する「Nexus」、ソースコードを静的解析する「SonarQube」にNRI独自のプラグインを加えた機能を持つ。アプリケーションのDockerイメージを資産として格納し、それをKubernetesリソースとしてテストするための環境も提供している。開発方式をモダナイズしたいという開発者の要望に応え開発され、利用が広まっている。

aslead DevOpsによる開発イメージ

　aslead DevOps展開までの過程で、社内の開発工程をモダナイズさせるためにどのようなプロセスで構築が進められたのかを説明する。

Dev、Ops、Infraの結束

　NRIにおける組織、開発文化の課題としてDev（アプリケーション開発）、Ops（運用）、Infra（基盤）に組織間の壁があることは第1回に述べた通りだ。近年のクラウドネイティブに関する動向を見ても「まずは組織を変えることが重要だ」と述べられているケースが多い。これはまさにその通りで、企業特有の組織文化やコミュニケーションを手軽に取れない環境が、サービス展開のスピードを高めることが難しくさせてしまう現実がある。

　そこでasleadではDev、Ops、Infraで組織間の壁が存在せず同じチームとして動いている。asleadの開発過程はNRIの他プロジェクトとは毛色が異なり、DevはOSS（オープンソースソフトウェア）に導入するNRI独自のプラグイン開発やデプロイを担当し、Opsは障害対応やQA対応、Infraはプライベートクラウド環境での必要リソースの構築、管理を担当した。

　最初の組織体制では社内のセキュリティポリシーを満たすプライベートクラウド環境を別チームに依頼して提供してもらっていたが、後に統合する形となった。この組織構成となったのはもともと人数の問題があったためであり、覚える業務が多くなるというデメリットもあるが、提供するプロダクトを全員が正しく理解できるというメリットもある。

Kubernetes採用に至るまで

　サービス開始当初はKubernetesを利用せずに運用をしていたが、サービスの運用コストが課題として挙がるようになった。そこで、運用コスト削減を第一の目標とし、副次的にリソース管理の負担軽減や自己回復性の担保を実施すべく、Kubernetesを採用した。Kubernetesは自動復旧やリソース割り当ての容易さに加え、多くの便利な機能がOSSとして提供されるエコシステムが確立していることも採用の背景にある。

　所属チームでは「Cloud Native Computing Foundation」（CNCF）の動向に注目しており、GitOpsを実現する「Argo CD」やChaos Engineeringを実現する「Litmus」などを内部で調査検証している。顧客を技術支援する際に効率良く展開できるようキャッチアップを行い、勉強会やWikiなどで共有している。このようなOSSをすぐに利用できるのもCNCFでI/F仕様の標準化が進められ、プラガブルな利用が可能なKubernetesならではといえる。

　Kubernetesは開発スピードが早いため、それに追随することでさまざまな機能を利用できる。また、オンプレミスにKubernetesクラスタを構築するか、各種クラウドサービスのマネージドKubernetesサービスを利用するかなど自分たちで構築場所を決められる自由度もある。

EKSでの運用

　当プロジェクトのKubernetes環境にはEKSを採用している。運用コスト削減を目的としていたため、AWSが提供するマネージドKubernetesサービスが最適と判断した。テスト環境を提供する上で、Kubernetesのコントロールプレーンに負荷がかかることも想定されていたため、高可用性やAWSリソースとの親和性も総合的に考慮した。

　EKSではKubernetesのマイナーバージョンのリリースが3カ月ごとに行われ、最新3バージョンがサポート対象となる。Kubernetesについて「バージョンアップに追随しなくてはいけない」ことがマイナスポイントとして挙げられることもあるが、Kubernetesのバージョンアップに合わせてエコシステムは開発が進み、機能も増えていくためそれに追従できる環境を構築することが大切だと考えている。

　ここからはEKSで運用するに当たって得られた恩恵を紹介する。

シングルクラスタ構成によるコスト削減

　以前は利用プロジェクトごとにApplication Load Balancer（ALB）で窓口を用意するようにしていたが、コスト削減のために1つのクラスタにつきALBが1つで済むようにリバースプロキシを適切に配置したり、複数のプロジェクトがある場合はNamespaceで区切ったりすることで、EKSのクラスタを無駄に増やさずコスト効率を高められた。

オートスケールによる可用性向上

　EKSでは「Cluster Autoscaler」や「Prometheus Adapter」という機能によりNodeとPodをオートスケールさせることができる。Nodeのオートスケール条件は決まっているが、Podに関しては自由に設定できるのでアプリケーションごとに設定することで適切なスケーリングができる。

適切なマニフェスト整備によるリソース管理の負荷軽減

　アプリケーション単位で「Helm Chart」を持っておくことで、複数のコンテナが1つのアプリケーションに含まれる場合でもリソース設定を容易にしている。利用者にはテスト環境を提供しており、デフォルトのリソース設定では不足に思う利用者もいた。Helm Chartの設定ファイルを編集してデプロイまでにかかる時間はわずかなため、利用者の意思で設定変更を素早くできるようになった。

　また、EKSとAWSの製品との親和性もここ数年で上がってきているのも実感している。以前は「IAM Roles for Service Account」や「AWS Timestream」が存在していなかったため、それらを補うために自分たちで実装する場面があった。「CloudWatch Container Insights」の機能も充実してきており監視ツールもマネージドサービスに任せることが可能になってきている。

今後の展望

　Kubernetesを運用して恩恵が得られた部分は複数あるが、改善の余地も同様に複数出てきた。

　まず、ステートフルアプリケーションのスケーラビリティをどう確保するかが挙げられる。AWSの場合、PersistentVolumeに「Amazon EBS（Amazon Elastic Block Store）」を利用するとReadWriteOnceの制約によりマウントさせるPodは1つだけに限定されマルチAZで冗長化できない。これを解決する方法として「Amazon EFS（Amazon Elastic File System）」などの共有ストレージの利用やストレージオーケストレーター「Rook」の利用が考えられる。もちろん、ただ冗長化すればよいものではなく性能など観点を広げて考えるべきである。当プロジェクトではAmazon EBSを使用しており、Rookを用いた冗長化を検討している。

Rookを用いたストレージ冗長化のイメージ

　次に、Kubernetesのエコシステムを柔軟に取り入れられていない点がある。本番環境にはHelmを用いてデプロイしているが、まだGitOpsを導入できていないために本番環境での手作業が必要になっている。GitOpsの導入はセキュリティ強化、視覚化、複数クラスタ管理などあらゆる点でメリットがあるので、Argo CDをはじめとするエコシステムを利用してこの問題を解決することを検討している。

　このように、Kubernetesの運用を自分たちで実施することでKubernetesを用いた技術支援をする際も知見として生かせられるようになった。また、若手メンバーは「CKA（Certified Kubernetes Administrator）」や「CKAD（Certified Kubernetes Application Developer）」といった外部資格を取得したり外部コミュニティーの勉強会に積極的に参加したりして、サービス展開に役立てている。

まとめ

　NRIでのKubernetes適用事例の一つとして、aslead DevOpsへの導入事例を紹介した。Kubernetesを採用したことでサービスの管理コスト削減や可用性の向上を実施できたと同時に改善の余地も判明してきている。今後はaslead DevOpsの一般提供に向けて注力し、Kubernetesを推進する存在を目指して活動していく所存だ。

　本記事がKubernetesの採用を検討している読者の皆さまの参考になれば幸いである。

筆者紹介

海内映吾

野村総合研究所でシステム開発ソリューションサービス「aslead」のインフラ設計を担当。

小林隆浩

野村総合研究所でデータベースを中心としたインフラ設計を担当。