ついに実用段階へ、Kubernetes上でステートフルアプリを稼働させるには：安心・安全に動かせる仕組みをヤフーが構築
実ビジネスを支える基盤としてKubernetesが企業に浸透する中、データを保持するステートフルアプリケーションも稼働させたいというニーズが高まっている。ヤフーではこれをコストや信頼性の観点でも安定的、効率的に動かす仕組みを構築したという。その中身とは。
Kubernetes as a Service環境でステートフルアプリに対応
コンテナとKubernetesが注目を集め始めて久しい。周知の通り、Kubernetesはコンテナアプリケーションのリリースやデプロイの高速化、運用自動化、障害の自動復旧など、ビジネス展開にスピードをもたらすとして導入企業が着実に増えつつある。
ただ、注意点も少なくない。その1つが、Kubernetes環境ではデータを保持しないステートレスなアプリケーション（以下、ステートレスアプリ）を稼働させることが一般的な中、データを保持するステートフルなアプリケーション（以下、ステートフルアプリ）を動かすためには、“それなりの仕組み”が必要になるという点だ。
コンテナは、データの永続性より、作成、廃棄を迅速、容易にすることで、システムとしての一貫性を保つことを重視したアーキテクチャだ。このため、例えばトランザクションの一貫性を保証する必要があるリレーショナルデータベース（RDB）や、ログデータを保護する必要がある監視ツールなどをコンテナで動かすのは簡単ではない。
ただ、実ビジネスで多様なアプリケーションをコンテナで稼働させるようになれば、ステートフルアプリをコンテナ環境で稼働させたいというニーズも増えてくる。そんな中、Kubernetes環境でステートフルアプリを運用できる基盤を構築し、本番環境で稼働させているのがヤフーだ。ヤフーのインフラを研究開発しているゼットラボの坂下幸徳氏は、こう説明する。
ゼットラボの坂下幸徳氏「世の中の変化に素早く対応することがビジネスにとって不可欠になっています。そのためには、早くリリースし、短い間隔でアップデートできる環境が欠かせません。ヤフーではその手段となるコンテナ／Kubernetesをさまざまな領域で活用できるよう、社内向けサービスとしてCaaS（Container／Kubernetes as a Service）を提供しています。このCaaS上で多数のステートレスアプリを動かしていますが、ステートフルアプリも使いたいという声の高まりを受けて、2020年夏にステートフル環境をサービスインしたのです」（坂下氏）
広告配信システムなど、ビジネスの中核領域でステートフルアプリを運用
現在、ヤフーでは広告、検索、データ分析など、ビジネスの中核となる領域でCaaSを活用している。2020年9月時点でKubernetesのクラスタ数は760以上、利用している開発チームの数は200以上、Kubernetesのノード数は1万9000以上、コンテナ数は19万9000以上という規模だ。
ヤフー サイトオペレーション本部の沼田晃希氏は、「CaaSでのステートフルアプリは、大きく3つの分野から活用をスタートしています」と話す。1つ目は広告領域で、Yahoo! JAPANや提携サイトのコンテンツページに広告を配信するシステムだ。ステートフル環境のサービスイン前からパイロットサービスとして、広告検索に利用するインデックス情報をストレージ上に配置することに取り組んでいた。広告の実データはオブジェクトストレージに格納しているが、インデックス情報だけで約80TBの規模になるという。
ヤフーの沼田晃希氏（ヤフー株式会社システム統括本部サイトオペレーション本部インフラ技術3部ストレージ1主務 リーダー／クラウドプラットフォーム本部技術2部CaaS2兼務）2つ目は、監査などのログの領域だ。全てのログを蓄積する基盤としてではなく、さまざまなシステムから収集したログを一時的に格納し、Kubernetes上のアプリケーションから素早く利用するためのシステムとしている。
「収集したログをコンテナアプリなどからサッと使えることがメリットです。ログは随時、必要なものだけを吸い上げてデータ分析基盤に送っています。容量は常に150TBの規模になります」（沼田氏）
3つ目は、OSSのモニタリングツール「Prometheus」のデータを一時保管する場所としての利用だ。ヤフーでは100を超えるサービスを提供しており、Prometheusによる監視データも多岐にわたる。開発者や運用者から「そうしたデータを一時的に置いておきたい」というニーズがあった際に、KubernetesのPodを立てて、その配下にログを置くといった使い方をしている。現在、ステートフルアプリの利用領域はさらに拡大しているという。
NetAppストレージを使ったKubernetes環境でのステートフルアプリ 実現のポイントは？
以上のようにKubernetes環境でステートフルアプリを実現する上で、大きく分けて2つのポイントがある。
1つは「Kubernetes環境への高度な対応」だ。というのも、ヤフーのビジネスを安定的かつ効率的に運用する上では、Kubernetesのメリットをしっかりと生かすことが前提となるためだ。
「例えば、当社ではインフラを効率良く運用することを重視しています。その点、ステートフルアプリとは単に『データを永続化しているもの』ですから、全てのデータに高度な保全性が求められるわけではありません。インフラを効率良く使うためには、データの価値やアプリケーションの特性に応じて、ストレージを容易に使い分けられた方がいい。その点、Kubernetesはストレージレイヤーを抽象化しますから、ハイパーバイザーのローカルディスクや外部ストレージを同じように扱えて、使い分けも容易にできるのです」（坂下氏）
「コンテナ／Kubernetes環境で動かすステートフルアプリ」のSLO（Service Level Objective：サービスレベル目標）も重視しているという。コンテナ／Kubernetesを使うことで、クラウドネイティブアプリケーションは頻繁にアップデートを繰り返すことができる。従って、SLOもそれに合わせた考え方が求められる。
「具体的には、SLOの中で特に稼働率の考え方が、コンテナ／Kubernetesに適したものかどうかを見定めていく点です。例えば年間稼働率が99.988%の場合、アップデートなど修理のために停止する時間は年間1時間ですが、これを下図のパターン1のように1時間にまとめず、パターン2のように毎月5分ずつ修理する形にしても同じ年間稼働率を達成できます。パターン2のようなアプローチでは、常に最新のバージョンを利用することができるだけでなく、回復力の強いサービスを作り上げることができます。ただ、このためにはいかに修理時間を短くするかがポイントになります。そのためにコンテナ/Kubernetesは有効だと考えています」（坂下氏）
その上で坂下氏は、従来のベアメタルサーバや仮想サーバでステートフルアプリケーションを稼働させているケースなど、パターン1のようにMTBFが可能な限り長くなるよう、堅牢（けんろう）なシステムを作り運用しているものも少なくないと語る。
「どれだけ堅牢なシステムを作っても壊れないものはないことを理解した上で、パターン2のような運用ができるアプリなのかの見定めが重要になります」（坂下氏）
このようにKubernetesを有効活用する上で、外部ストレージには「Kubernetes環境への高度な対応」が強く求められたというわけだ。その点、ネットアップはKubernetes環境への対応に力を入れており、コミュニティーへの貢献度が高いことでも知られている。特に、Kubernetesのコンテナストレージインタフェース（CSI）「Trident」をOSSで開発、提供しており、多くの企業から高評価を獲得していることも決め手になったという。CSIの規格では、ボリューム作成、クローン作成、スナップショット作成などの機能ごとに要件が決められているが、Tridentはこのほぼ全てに対応している。
もう一つ、選定のポイントは「ストレージに求められる基本要件を満たしていたこと」だ。
「ヤフーのサービスは、社会インフラの役割を担っているものも多くあるため、『ストレージに格納されたデータも絶対に消えてはいけない』という考え方を基本とします。例えば、サービス稼働率は厳しいもので99.99%、月間5分以下を目指しています。これを実現するためには拠点内や拠点間でのデータ冗長化などサービスレベルに応じた最適な構成で運用しています。また、独自システムによる傾向分析や監視方式の採用など、プロアクティブなサービス監視を行い稼働率100%の維持に努めています。しかし、まずはストレージ本体が優れた基本性能を持っていることが大前提です。NetAppストレージはこの点も満たしていました」（沼田氏）
マルチテナントによるセキュリティと、作り込みの柔軟性も評価
とはいえ、Kubernetes環境に対応し、かつ高性能な外部ストレージは複数存在する。そうした中でNetAppストレージを選んだポイントは何だったのか。
「大きく2つあります。1つはマルチテナントによる高度なセキュリティです。NetAppストレージはマルチテナントの仕組みが優れており、高度なセキュリティを確保できました」（沼田氏）
もう1つは「サービスの特性に応じた柔軟なストレージ運用ができること」。例えば、1つのストレージに対して複数のサービスがアクセスすると、あるサービスは高速なSSDが必要な一方、他のサービスはHDDで十分といったケースもある。
「そうした際は、サービスが求める性能要件に従って提供するディスクを柔軟に変えています。NetAppストレージでは単一のシステムでSSDとHDDの混在構成が可能なためコストを大幅に抑えることが可能です。このように、サービスの特性に応じた構成が組める点も評価ポイントの1つです」（沼田氏）
なお、ネットアップ ソリューション技術本部の豊村理一郎氏によると、「マルチテナントによる高度なセキュリティ」については、ストレージ環境の仮想マシンである「SVM（Storage Virtual Machine）」機能で実現しているという。
ネットアップの豊村理一郎氏（ソリューション技術本部 SE第1部 ソリューションズエンジニア）「アグリゲートと呼ばれるディスクグループとSVMを1:1で対応させることで、高度なセキュリティだけでなく利用可能容量の制限やノイジーネイバーを回避する環境の提供を可能としました。一方で開発環境などコストを優先したい環境向けには共用のアグリゲートから容量を提供する方式を採用し、柔軟な構成を実現しています。またヤフーさまはアグリゲート共用環境で必要となる容量の監視や管理の仕組みなどネットアップの機能では不足している部分を独自開発することで、Kubernetesステートフル環境をより効率的に運用されています」（豊村氏）
坂下氏は「アプリケーションの特性に応じて、サービスの安定性、セキュリティ、コストなどのバランスをとることで、こうした柔軟な作り込みができる点もネットアップの良さだと思います」と話す。
ネットアップとの“One Team”で加速するステートフルアプリ活用
坂下氏は、「ネットアップのプロダクト開発体制は、Kubernetes活用に適した体制になっていると感じます」と総評する。
「Kubernetesは3カ月に1回バージョンアップしますが、CSIドライバーのTridentもそれに合わせてバージョンアップされます。また、Trident はOSSですから、障害が発生してもソースコードから素早く問題を特定できます。ネットアップの開発者とGitHubやSlackなどのオープンな場で直接コミュニケーションができる点もメリットです」（坂下氏）
ネットアップの小久保毅氏（営業第2本部 第1部シニアアカウントマネージャ）一方、沼田氏は、「Kubernetesを利用した環境ではコンポーネントが多くさまざまなチームが関係してきます。その中でもストレージレイヤーはCSI規格により抽象化されていることから開発者とストレージ担当の連携はより強固に必要となります。チームの枠組みを超えてシステムを理解するために各チームの兼務制度やチームをまたいだ勉強会、外部セミナーへの参加など、情報収集を積極的に行っています」と語る。
無論、この体制にはネットアップのエンジニアやサポートも含まれる。ネットアップ 営業第2本部の小久保毅氏は、こうした運用体制を「One Team」と表現する。
「Tridentの開発、提供や、ストレージのKubernetes対応もそうですが、ネットアップのプロダクト開発の在り方は大きく変化しています。これからはストレージがアプリケーションと連携し、サービスの一部として機能することが重要です。ネットアップでは、そうしたお客さまの動向や要望を受けて、多様なチームがバーチャルで一体となってサポートできる体制を整えています。今後もお客さまと共にOne Teamで取り組みを進めていくつもりです」（小久保氏）
One Teamは現在も進行中だ。今後は各リージョン内にある各データセンターの棟をまたいでKubernetesクラスタを構成する「マルチAZ」を実現するという。ヤフーにおけるKubernetes上でのステートフルアプリ活用は、ネットアップとのOne Team体制でますます加速していきそうだ。
ヤフーも登壇予定！
Copyright © ITmedia, Inc. All Rights Reserved.
提供：ネットアップ合同会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2021年3月24日
ITmediaはアイティメディア株式会社の登録商標です。