クラウドネイティブなインフラとクラウドネイティブ・アプリケーションプラットフォーム（CNAP）

クラウドネイティブなインフラはハードルが高い

クラウドネイティブなインフラは使いこなすことができれば DX を加速させる武器となります。しかし使いこなすまでのハードルが非常に高いことがクラウドネイティブなインフラの欠点となります。クラウドネイティブなインフラで DX を推進したという事例が頻発していない理由がこの点にあります。

クラウドネイティブなインフラのハードルを上げている要因として私は 2 点あると考えております。

1 点目はクラウドネイティブなインフラは考慮すべき範囲が広いことです。CNCF が発行している Cloud Native Trail Map を見てみます。Trail Map はシステムをクラウドネイティブ化するための指針です。これを見るとシステムをクラウドネイティブ化するためには CI/CD、監視、ネットワーク、セキュリティなどのアプリケーション周りの幅広い分野について考慮する必要があることがわかります。

2 点目はそれらの各分野における技術調査から IaC 化までのハードルが高いことです。​各分野における取り組み方ですが、私はこちらの 3 ステップになると考えています。​

1. その分野のベンチマークやベストプラクティスと呼ばれている設計方針を調査する
2. ​調査した設計方針を自分たちの環境においてどのように実現するのか設計する​
3. コード（IaC）化する​

この 3 段階のステップをシステムのクラウドネイティブ化において考慮すべきとされる各分野において実施していく必要があります。

【具体例】セキュリティ分野における技術調査〜 IaC 化

前述したクラウドネイティブなインフラを構築するための 3 ステップについて理解を深めるために、ここでは具体的にセキュリティ分野を例に取って各ステップを追ってみます。

Step1. ベンチマーク・ベストプラクティスの調査

まずはベンチマーク・ベストプラクティスの調査を行います。クラウドセキュリティの分野においては NIST CSF、ISMS、CIS Control などが代表的なベンチマークとなります。これらのベンチマークから自分たちのシステムに関連する項目を選択します。今回は例として、パブリッククラウドのアクセスに必要なアクセスキーなどのクレデンシャル情報の管理について考えてみます。

CIS Control によると「アプリケーションで使用するパブリッククラウドのクレデンシャルは 90 日以内にローテーションすること」が推奨されています。

さらにこのベンチマークに関連するベストプラクティスを調査すると、クレデンシャルのローテーションが運用面を考慮した場合に大変になるので、そもそもクレデンシャルを自分で管理すべきではないということがわかります。

ここまでがベンチマーク・ベストプラクティスの調査で実施する内容になります。

Step2. 各環境における設計

次に先ほどの調査結果を自分たちのシステム上でどのように実現するかを設計します。ここではパブリッククラウドで提供されているマネージドの Kubernetes 環境にあるアプリケーション Pod からパブリッククラウドのマネージドリソースへアクセスする場合を考えてみます。Pod で動くアプリケーションコンテナにクレデンシャル情報を埋め込んでしまえばマネージドリソースへのアクセスは容易です。しかしベンチマーク・ベストプラクティスに従うとそれは推奨されません。クレデンシャル情報をアプリケーションへ埋め込むことなくマネージドリソースへアクセスする方法を調査し設計する必要があります。

結論としては Google Cloud が提供しているマネージド Kubernetes を利用しているのであれば Workload Identity、Azure であれば Azure AD Workload Identity、AWS であれば IAM Roles for Service Accounts という技術を使用することでクレデンシャル情報を管理せずにマネージドリソースへアクセスすることが可能です。

このように自分たちの環境に合わせてベンチマーク・ベストプラクティスをどのように実現するのかを調査・設計する必要があります。

また補足ですが、Kubernetes を提供しているクラウドベンダーとは別のベンダーで管理されているリソースへクレデンシャル情報を管理せずにアクセスすることも可能です。AWS から Google Cloud、Azure から Google Cloud への連携については以前に記事を書いたのでそちらも参照してください。

• Workload Identityを用いてEKSクラスタからGoogle Cloudへアクセスする
• Workload Identityを用いてAKSクラスタからGoogle Cloudへアクセスする

Step3. コード（IaC）化

最後に設計を IaC のコードに落としていきます。ここでも自分たちのシステムや環境、開発方針に合わせて最適な技術を選択する必要があります。

単純に IaC 化と言っても数ある選択肢が存在します。マルチクラウドを見据えて IaC の運用を統一するために汎用的な Terraform を使用するのか、各パブリッククラウドに特化した AWS の CloudFormation や Azure の ARM Template を使用するのかを選択する必要があります。またパブリッククラウドのマネージドリソースを Kubernetes のリソースとして管理したいのであれば Google Cloud の Config Connector、AWS Controllers for Kubernetes、Azure Service Operator などの選択肢もあります。このような様々な技術スタックの中から自分たちのシステムや環境、開発方針に最適なものを選択して実装する必要があります。

以上がクラウドネイティブなインフラを構築する上での技術調査から IaC 化までの流れです。セキュリティ分野のクレデンシャル管理という項目だけを考慮した場合でもこのように複数の技術を調査し、その技術によって目的を実現できるかを検証する必要があります。

クラウドネイティブなインフラによりアプリケーションエンジニアの負荷が増大している

前述したようにクラウドネイティブなインフラを構築するためには幅広い分野において技術調査から IaC 化までを行う必要があります。

ではいったい誰がこのクラウドネイティブなインフラを構築するのでしょうか。SRE チームなどが専任で担当するのであれば良いのですが、多くの企業では、アプリケーションエンジニアがビジネスロジックを開発する傍らでこのクラウドネイティブなインフラの構築も担当しています。

パブリッククラウドやコンテナ技術の進化により従来のアプリケーションエンジニア、インフラエンジニアの境界が曖昧になり、アプリケーションエンジニアが監視方式の検討や CI/CD パイプラインの作成などを担当するのは自然の流れではあります。しかし、このクラウドネイティブなインフラというものはビジネスロジック開発の傍らで構築できるような負荷の軽いものではありません。

その結果として以下のような問題が発生します。

• CI/CD パイプラインの一部に手動部分が残り、DX の推進に欠かせないはずのリリース頻度が低下する
• セキュリティベースラインを満たせずにリスクが増加する（前述の例だと、時間がないのでとりあえずでクレデンシャル情報を直接アプリケーションに埋め込んでしまうなど）
• パブリッククラウド・OSSのアップデートに追従できない

Infrastructure as Low Code

では、アプリケーションエンジニアの負荷を軽減するためにはどうしたら良いでしょう。

その解決策となるのが「Infrastructure as Low Code」です。Infrastructure as Low Code の世界ではあらかじめ IaC のコードをパッケージに集約します。Kubernetes を中心としたクラウドネイティブ技術のエコシステムには数え切れないほどの OSS が存在します。また、現在パブリッククラウドにも数え切れないほどのサービスが存在します。またそれらそれぞれに多数の設定可能なパラメータが存在します。これらを組み合わせると無数の選択肢となります。Infrastructure as Low Code の世界ではこれらの組み合わせの中からよく使われる組み合わせやベストプラクティスと呼ばれる組み合わせをあらかじめ選択してパッケージ化しておきます。そうすることでユーザは固有の設定値をパッケージに入力するだけで適切なインフラを構築することが可能となります。これが Infrastructure as Low Code です。これによりアプリケーションエンジニアのインフラ構築の負荷を軽減することが可能です。

クラウドネイティブ・アプリケーションプラットフォーム（CNAP）でアプリ開発社の負担を軽減

我々のチームでは Infrastructure as Low Code の世界を実現するためにクラウドネイティブ・アプリケーションプラットフォーム（CNAP）というプラットフォームを開発しました。CNAP はクラウドネイティブな各分野におけるベンチマーク・ベストプラクティスが各環境に最適化された IaC となってパッケージ化されています。

アーキテクチャ図で例示します。ほんの一例ですが、ネットワークでは Kuberentes 内の Service を各パブリッククラウドのマネージド DNS サービスに登録する External DNS が導入されていたり、Istio を用いたサービスメッシュ機能が導入されていたりします。監視の分野においてもデファクトスタンダードになっている Prometheus、Grafana が使用可能です。またこれらはすべて GitOps によりアプリケーションと同様の方式でデプロイすることが可能です。

また、その他に注目しておきたい CNAP の特徴として 2 点挙げます。

1 点目は CNAP は構築だけではなく運用の負荷も低減するプラットフォームということです。

パブリッククラウドや Kubernetes を含む各種 OSS は日々アップデートされています。そのアップデートに継続的に対応していくのは非常に労力のかかる作業です。CNAP では内部の開発チームでそれらパブリッククラウドや OSS のアップデートを検証しパッケージに反映していくため、提供しているパッケージは常に最適な状態となります。そのためユーザがパブリッククラウドや OSS のバージョンアップを気にする必要はありません。

2 点目は CNAP は OSS で構成されたオープンなプラットフォームであるということです。

プラットフォームと聞くと、それを導入したことによって開発が制限されてしまうのではないかと考える方も多いと思います。しかしその心配はありません。CNAP を導入したからといってアプリケーション開発、インフラ開発に何か制限がかかることはありません。逆に CNAP の一部機能だけを使うといった使い方も可能です。

まとめ

本記事では、我々のチームで開発している CNAP というサービスについて、CNAP が解決しようとする課題、CNAP の設計のベースとなる Infrastructure as Low Code という概念、そして CNAP とは何かについて整理してみました。

CNAP についてもっと知りたいと興味を持っていただけた方は、直接説明することも可能ですのでぜひお気軽に CNAP のサービスページからお問い合わせしてみてください。ありがとうございました。

では、ソフトバンク Advent Calendar 2022 の 20日目にバトンを渡します。劉 暁晨さんよろしくお願いします！

関連サービス