クラウドネイティブアプリケーションの運用基盤としてデファクトとなったKubernetes。稼働させるワークロードも多様化し、金融業などをはじめ、収益を担う一般顧客向けアプリケーションをKubernetes上で動かすケースも増えている。これに伴い、注目を集めているのがミッションクリティカルなビジネスを支える「データを保持することが求められるステートフルアプリケーション」のKubernetes上での運用だ。これを効率的かつ安全に動かすポイントとは何か? Kubernetesに詳しいゼットラボ、NRI、ネットアップに所属する三者に話を聞いた。
デジタルトランスフォーメーション(DX)の取り組みが加速する中、クラウドネイティブな技術や開発、運用アプローチが大きな関心を集めている。中でも、Web企業のみならず、金融、製造などをはじめ、一般企業の注目度も高いのがコンテナオーケストレーションツールのKubernetesだ。アプリケーションを開発、改善、提供するスピードがビジネス差別化のカギとなり、DevOpsやCI/CD(継続的インテグレーション/継続的デリバリー)に取り組む企業も増える中、クラウドネイティブアプリケーションの運用基盤としてデファクトとなっている。
これを受けて、Kubernetes上で稼働するワークロードが多様化する中、キーワードとなってきたのが「ステートフル」だ。これまでは、Kubernetes上で動かすコンテナアプリケーションはデータを保持せず、アプリケーションが終了すればデータも消えてしまう「ステートレス」アプリケーションが中心だった。だが、収益向上を担う社外の一般顧客向けのアプリケーションとして、顧客の個人情報やサービス利用履歴など「データを持ち続けなければならない」ミッションクリティカルなワークロードを動かすケースも増えてきた。そうした中で、「いかに効率よく、安全、安定的に、ステートフルアプリケーションを運用するか」というテーマがKubernetes活用において今注目を集めているのだ。
では具体的に、Kubernetesでのステートフルアプリケーション運用では何がポイントになるのか。ヤフーにおけるKubernetes運用や、Kubernetes関連コミュニティーで広く知られるゼットラボ 須田一輝氏と、Kubernetes導入の各種検証作業を行い金融分野にも知見を持つ野村総合研究所(NRI)の小林隆浩氏、そしてステートフルアプリケーションを支えるためのドライバーを提供しているネットアップの小久保毅氏という、“エンタープライズでのKubernetes活用”に詳しい三者に話を聞いた。
――クラウドネイティブへの関心が高まる中、Kubernetesを利用したいという企業ユーザーはかなり増えたと思います。皆さんは現状をどうご覧になっていますか。
小久保氏 実は2019年の弊社主催イベント「NetApp INSIGHT TOKYO」で須田さんに登壇いただき、Kubernetes活用やステートフルに関してご講演いただいたのですが、大きな反響が得られました。「Kubernetesは本番運用に耐える、ビジネスを支えられる」ということを参加者の皆さんがあらためて実感されたのだと思います。
須田氏 私が主催しているKubernetesの勉強会「KubernetesTokyo」の参加者数からも注目度は分かります。2016年5月に開かれた第1回の参加者は応募244人でしたが、回を重ねるごとに人数が増え、最近では500人を超えました。オンラインのみでの開催では1000人を超える規模になっています。
――どういった業種の企業が関心を持っているのでしょうか。
須田氏 当初はヤフーのようなWeb企業が中心でしたが、最近は「Red Hat OpenShift」を利用する銀行など、金融をはじめ多様な業種で注目度が増していると感じます。
小林氏 私はNRIで「aslead」という多角的な開発支援を行うツールを提供する部署にいるのですが、金融業でも使われるお客さま向けのツールを1年以上前からKubernetesで動かしています。また、社外向けスマホアプリケーションなど、収益を担うビジネスアプリケーションについても、新規プロジェクトではコンテナを使うことを前提とすることが増えています。既存のアプリケーションをKubernetesで動かすことについても、これから進むという認識です。
――金融をはじめ、多くの企業がビジネス展開のスピードアップを重視しているわけですね。ただ、金融のようなミッションクリティカルな業態の場合、スピードと共に、安全性や安定性、すなわちアプリケーションの品質も求められると思います。
小林氏 そうですね。コンプライアンス担保は重要な課題です。事実、CI/CDのうちCIはこれまでもできていたという企業は多いのですが、CDの部分はこれからだと思います。例えば、品質保証部門との関係やテストの在り方など、「自動的にアプリケーションがデプロイされる」ことが文化的に許容できない部分が残されています。ただ、ビジネスにスピードが不可欠となっている以上、これも時間が解決していくと考えます。
――ヤフーではKubernetesをどう利用しているのですか。
須田氏 2017年7月からオンプレミスのサービス本番環境で利用を開始しました。今は数多くのサービスで利用しています。Kubernetesクラスタの数でいえば当初は5クラスタから開始し、1年後の2018年7月には50クラスタ、2019年7月では400クラスタで運用しています。これを支えているのがゼットラボが開発している「Kubernetes as a Service」(以下、KaaS)というマネージドKubernetesサービスです。クラスタの作成や削除、アップグレード、障害が発生したときのワーカーノードの復旧などを自動化することで、クラスタが増えても運用の負荷やコストを増やさずに管理できます。
――一般にKubernetesを自社で利用する場合、どんな点に苦労しがちなのでしょう。
須田氏 コンポーネントが多い点でしょうか。暗号化を含めてさまざまな通信が走っているため、複雑で、何かトラブルがあったときにLinuxやOSS(オープンソースソフトウェア)の知識が必要になります。特にAmazon Web Services(AWS)やGoogleなどのKubernetesマネージドサービスを使わず、オンプレミスで構築、運用するなら、その辺りの知識は必須です。もう一つはリリースサイクルをキャッチアップすること。Kubernetesは3カ月に一度リリースがありますから、そのたびに変更の差分を調べて対応しなければなりません。
そこでKaaSでは、本来、人が行うクラスタのアップグレードなどをソフトウェアで自動化することで効率化し、オンプレミスでも「Amazon Elastic Container Service for Kubernetes(Amazon EKS)」や「Google Kubernetes Engine(GKE)」と同じように、開発者がサービス開発に専念できるようサポートしているのです。
――ではヤフーにおいて、Kubernetesではどんなアプリケーションを稼働させているのでしょうか。
須田氏 永続データを持たないサーバなどのステートレスなアプリケーションが多いです。ヤフーでは、SQLやKVS(Key Value Store)などのデータを扱うプラットフォームを自社開発してサービスとして社内に提供しています。各コンテナのデータを一括してそこに持つことで、Kubernetes上でのアプリケーション運用を効率化しているのです。
Kubernetesの魅力は、ビジネスからのフィードバックを素早く取り込み、開発ライフサイクルを迅速に回せることにあります。また、「セルフヒーリング」など障害に強い機能を持ち、安定運用が可能なことも魅力です。今後はステートレスだけでなく、ステートフルな領域でもKubernetesを活用していこうとしています。
――一般に、ステートレス、ステートフルと言っても、具体的にどう違うのか、イメージしにくい部分もあると思います。あらためて、違いを教えていただけますか。
須田氏 MySQLなどのRDBMSやKVS、オブジェクトストレージといった「データを保持するアプリケーション」をステートフルと捉えています。ヤフーでは今これらを仮想マシンやベアメタルで運用していますが、より安定した運用のためにコンテナとKubernetesを使いたいというニーズが社内にあります。
小林氏 NRIでは、CIを動かすためのコンポーネントの大部分をステートレスなコンテナで実行していますが、ソースコードやバイナリを格納するリポジトリはステートフルです。業務データを格納するデータベースも当然ステートフルだと捉えています。
――つまり、「データを保持するものかどうか」がステートレスとステートフルの違いというわけですね。ただ、データを保持するステートフルアプリケーションをKubernetesで動かすには、Pod(ポッド)内の一時データ領域を使う方法、Node(ノード)内のデータ領域を使う方法、外部の永続ストレージを使う方法があります。これらの使い分けはどう考えるべきでしょうか。
須田氏 クラスタの中に永続データ層を組むことはできるのですが、「最悪消えてもいいデータ」と「絶対に消えてはいけないデータ」をきちんと分けて使うことが必要だと考えています。例えば、顧客情報や企業の機密情報を消えてもいいデータと同じように扱うことはできません。そこで安全に運用する上で現実的な選択肢となるのが、外部の永続ストレージの利用です。
小林氏 そうですね。特に顧客の重要データを扱う金融業界では、安全性と信頼性の高い外部ストレージに永続データを保存することが必須となってきます。
――ただ「Kubernetesではストレージの取り扱いが難しい」という開発エンジニアの意見を聞いたことがあります。
小林氏 確かにコミュニティーでもそうした意見はよく聞きます。例えば、アプリケーションエンジニアが、触ったことのなかったストレージを触ってみたらうまくいかなかった。それで怖いとなってしまう。ただ、これはストレージエンジニアがKubernetes領域でまだ情報を発信していないことの現れだとも言えます。コミュニティーを見ていて面白いのは、ストレージエンジニアとアプリケーションエンジニアの領域がオーバーラップし始めていることです。私はオーバーラップが進む中で「簡単だ」「面白い」と感じ方が変わっていくはずだと見ています。
――ではそうした現状がある中で、「コンテナ、Kubernetes時代のストレージ」に求められる要件は何でしょうか。
小林氏 インフラエンジニアとしてみるとこれまでのノウハウを生かしながら、Kubernetesから既存ストレージを運用しやすいことが挙げられると思います。アプリケーションエンジニアの視点でいえば、クラウドのストレージサービス、例えばAWSなら、ブロックストレージの「EBS」(Amazon Elastic Block Store)やファイルストレージの「EFS」(Amazon Elastic File System)と同じような使い勝手で従来のストレージもKubernetesから使えることでしょうね。
須田氏 ストレージは個人やユーザー企業単独で簡単に構築できるものではありません。障害の保全や、可用性の維持、セキュリティなど、長年蓄積してきたノウハウや技術で信頼を担保してきた分野です。それをこれから自社でやろうとしてもペイしません。「信頼できるものを使う」という選択が良いと思っています。
――既存の知識が生かせること、使いやすさ、障害保全、可用性、信頼性――これらはクラウドシフトに向かうエンタープライズにとって非常に重要な要件だと思います。ネットアップはこうした期待にどう応えているのですか。
小久保氏 まずKubernetesに対しては今後も最大限の投資をしていくことを経営トップが明言しています。個別のソリューションでいえば、OSSで開発している「Trident」があります。TridentはネットアップストレージとKubernetes環境をつなぐためのプラグインです。Kubernetes Container Storage Interface(CSI)という規格に対応していて、Kubernetesの標準APIでネットアップストレージを操作し、Kubernetesクラスタでステートフルなアプリケーションを運用できるようになります。つまり、Kubernetesによるオーケストレーションや永続ストレージのプロビジョニング、プロビジョニング解除を効率化できるのです。
――こうしたネットアップのソリューションについてどう評価されていますか。
須田氏 ネットアップはヤフーでも長く使ってきた実績あるストレージです。データ保護については圧倒的な信頼性があります。Kubernetes環境を強力にサポートしている点も心強いです。Tridentについても、マルチテナントの権限管理機能などについて社内で検証して、しっかりと対応していることを確認しています。OSSなのでトラブルシューティングの際にソースコードを見て原因を追究できることも大きなメリットです。
ネットアップストレージの特長:高度な信頼性、優れたデータ保護機能、柔軟な容量拡張/縮小、重複排除機能、ワークロードごとのパフォーマンス制御機能などを持つ。国内でも多数の企業の支持を誇る。
小林氏 NRIが重視しているのは、マルチクラウド、ハイブリッドクラウドへの対応です。例えば金融業では、「コンプライアンスが厳しいアプリケーションの開発や運用は自社データセンターで、よりスピードが必要なものはパブリッククラウドで」という声が多いのですが、ネットアップはこの点に応えていると考えます。
具体的な製品でいえば、クラウド環境とデータを自動的に同期、複製する「NetApp Cloud Sync」や、ストレージOSの「NetApp ONTAP」をオンプレとクラウドの両方で利用でき、ハイブリッド環境でも、“既存の知識とノウハウで”一元的にデータを扱える「NetApp Cloud Volumes ONTAP」などの検証を行っています。Tridentのマルチクラウド対応なども検証していきたいと思います。
NetApp Cloud Sync:オンプレミスのデータ、あるいはクラウド上のNASのデータを、Amazon S3、Azure Blob Storage、IBM Cloud Object Storagesと同期できるデータ管理サービス。NASのインフラと各クラウドサービスとの間にセキュアかつ高速な経路を形成し、コスト効率の高いデータ転送を実現する。
Cloud Volumes ONTAP:ネットアップストレージのストレージOS「ONTAP」をクラウド上に展開可能としたソフトウェアデファインド型のONTAP。ONTAPの各種データ管理機能をAWSやAzureでも利用できる。NFS/CIFS/iSCSIを統合したストレージアクセスや、重複排除と圧縮、暗号化、スナップショットなどを実現。以前から定評ある遠隔地レプリケーション機能「SnapMirror」、バックアップ機能「SnapVault」も利用可能。
――Tridentの評価はいかがでしょうか。
小林氏 クラウドとオンプレミスの両方のKubernetesクラスタから、ネットアップストレージに対して動的にボリュームをプロビジョニングすることが可能になります。これによりマルチクラウドの使い勝手が大きく向上すると見ています。
須田氏 確かに、Kubernetes標準の方法で外部の永続ストレージを使えるという意味でTridentは非常に良いツールですね。ネットアップストレージは、専用ストレージとしての機能が充実していることも挙げられます。具体的にはポリシー制御に対応しているので、帯域制御やマルチテナンシーなど、従来のストレージで使っていた細かい制御が可能なのです。
――すなわち、オンプレミスにクラウド同様の、使いやすく迅速、柔軟な環境を整備できるのはもちろん、Kubernetes上で動かすミッションクリティカルなステートフルアプリケーションについても提供スピード、安定性、可用性を担保できるわけですね。
小林氏 そうですね。クラウドネイティブな環境で、専用ストレージ装置を、従来通りの高いレベルで、従来の知見を使って活用できる。アプリケーションエンジニアにとっても外部ストレージをKubernetesのやり方で使いこなせるようになる。これは大きなメリットだと思います。
――Kubernetesを、今後どのように使っていく予定ですか。読者に向けたメッセージとともに教えてください。
小林氏 今後はお客さまの基幹システムもKubernetes上で運用する形になっていくでしょう。そこで使われるデータの格納先として、Tridentを使ったネットアップストレージ環境を活用し、ステートフルアプリケーションをKubernetes上で動かすノウハウを蓄積していく考えです。個人的にもステートフルに注目しているので、PostgreSQLなどをKubernetesで動かして検証し、その結果を紹介するなどしてコミュニティーを盛り上げていきたいと思っています。
須田氏 実はTridentを使ったネットアップストレージをもうすぐ、社内のプロダクション環境として提供する予定です。サービス開発側からも、永続ストレージとKubernetesを組み合わせてアプリケーションを運用したいというニーズは日々いただいています。まずはそれにしっかり応えていきます。その次は、KubernetesクラスタのマルチAZ(アベイラビリティゾーン)による冗長化です。Tridentによる検証も済んでいるので、時期を見て取り組んでいきます。また、ステートフルアプリケーションを自動的に運用する「Kubernetes Operator」や「Controller」を活用し、さらなる運用自動化を目指したい。そうした発表でコミュニティーも盛り上げていきたいです。
――Kubernetesがクラウドネイティブアプリケーションの運用基盤としてデファクトになり、多くの企業にとってステートフルアプリの運用が不可欠になりつつある今、ネットアップが果たすべき役割は大きそうですね。
小久保氏 そうですね。弊社としてはデータレイヤーを中心にKubernetesを最大限サポートしていきます。Tridentをはじめ、これから登場するソリューションを含め、クラウドネイティブを志向するお客さまを万全の体制でサポートするとともに、コミュニティーにも寄与していきたいと考えています。
ゼットラボではKubernetesを中心としたCloud Nativeアプリケーションを支えるインフラ技術のR&Dを行っています。本文で触れているKaaSやKubernetesにご興味のある方は以下の資料をご覧ください。
野村総合研究所(NRI)の「aslead」は、システム開発などの生産性向上のための製品やソリューションに加え、技術サポート、導入支援、システム運用のサービスを提供しています。詳しくは以下のURLをご覧ください。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:ネットアップ合同会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2020年5月28日