クラウド ではなく クラウドネイティブ を選択する理由

こんにちは。CTC Build サービスで、Engagement と Engineering の谷間を quest している DevOpsエンジニアです。

昨今の DX 旋風でクラウドの活用は叫ばれていますが、build service がアーキテクチャとしてファーストプライオリティで選択するクラウドネイティブに関して綴ってみたいと思います。

「クラウド」の活用と「クラウドネイティブ」の活用の、ちょっとしたニュアンスの違いをご理解いただけたら幸いです。

なぜ クラウドネイティブ を選択するのか？

エンジニアのリソースを IT システムが生み出す価値の源泉である 「アプリケーション開発」 に集中させるためです。

御社のエンジニアが SRE を極めて、限りなく堅牢な基盤を準備できるようになったとしても、利用者に価値を提供するアプリケーションを開発することができなければビジネスが成立しません。

新規ビジネスの立ち上げでは、利用者に価値を提供できるアプリケーションの開発がファーストプライオリティになります。同じエンジニアリソースを投入するのであれば、「アプリケーション開発」にリソースを集中できる環境を、という要件に対して今現在最もマッチしている構成が クラウドネイティブ です。

以降、「Web サイトでメールアドレスがリストされたファイルを受信して、リストのアドレスにメールを送る」というシステムを例に、オンプレミスとクラウド、クラウドネイティブの比較で必要なエンジニアリソースの違いを見ていきます。（例にしている業務にちょっとレガシー感ありますが。。）技術的に言い換えると、「Webアプリのバックエンドで非同期処理を実行するシステム」という感じです。

「オンプレミス」と比較した「クラウド」

Java系でインプリした場合のオンプレミス実装を例に構成を見ていきます。Queue として JMS コンテナを起動させて MDB(Message Driven Bean) で処理させてみましょう。

構成としては、以下のような感じになります。

実際に環境を作るとすると、いろんな技能を持ったエンジニアが必要です。それぞれのサーバーと、一部の機能にはクラスタリングのための共有ストレージを配備する必要があるので、基盤構築を担当できる技能を持ったエンジニアが必要です。ロードバランサーを使用してフロントエンド部分を冗長構成/負荷分散させるため、ネットワーク系の技能を持ったエンジニアも必要でしょう。Java系のミドルウェアをクラスタリング構成できるエンジニアも必用になります。これらのエンジニアが構成した環境の上で、開発者が作ったアプリが動作して、利用者へ機能を提供することができます。

次に、これらの構成をクラウドへ「リフト」するとどうなるかを見てみます。（アプリケーションに極力手を入れない構成を考えてみました）

サーバが起動していた部分が、クラウドサービスのコンピュートリソース系のサービスが提供する仮想マシンに置き換わります。ロードバランサーは、クラウドサービスが提供するマネージドサービスに置き換わります。ネットワーク担当はクラウド基盤担当が兼務してしまうでしょう。必要なエンジニアリソースが少し削減されましたが、インパクトがある変化ではないですね。(ただし、infrastructure as code の導入で、実際のところの基盤担当の業務負荷は大幅に削減されています)

「クラウド」と比較した「クラウドネイティブ」

最後に、build service がアーキテクチャとしてファーストプライオリティで選択するクラウドネイティブなアーキテクチャです。

仮想マシンによる機能提供を避けて、マネージドサービスを選択します。OSやミドルウェアの準備が不要となるため、アプリケーション開発にリソースを集中できます。Webフロントエンドは、function as a service または PaaS系マネージドサービスを使用します。スタティックコンテンツの提供用に Webサーバをインストールした仮想マシンを起動させるようなことはしません。Queue は、どのクラウドでも提供されているマネージドサービスを使用します。非同期処理実行部分も function as a service (場合によってはコンテナ系のバッチ処理サービス)を選択して、仮想マシンは使用しません。

まとめ

Kubernetes が出てくると思ったかた、期待が外れましたでしょうか？

k8s をはじめとしたコンテナでのサービス実装も、基本的にはセカンドプライオリティです。（コンテナイメージの作成/管理にもエンジニアリソースが必要なため）

既存システムの移行であれば、「仮想マシンよりマシか。。」的な感覚でコンテナ環境へ移行する場合もあるかもしれませんが、build service の主なターゲットは、まだ世に出ていない新規ビジネスの基盤を支えるITシステムです。この要件に応えるために、クラウドネイティブの中でもマネージドサービスを使用したクラウドネイティブを選択して、エンジニアリソースをアプリケーション開発に集中させています。

（もちろん、必要に応じて、コンテナや k8s 構成も選択しますよ！ビジネスが成長してシステムが大規模化してきたら、コンテナ k8s への移行は要検討ポイントです。）

ということで、build service のクラウドネイティブのお話でした。

build serivice では、最新のクラウドネイティブ技術に対するスキルと関心を持つエンジニアを募集しています。気になるかたは、こちら(CTC Buildサービス推進チーム)もどうぞ。