いちばんやさしい「クラウドネイティブ」

これは クリエーションライン アドベントカレンダー 2023 の 8日目 の記事です。

はじめに

こんにちは。カスタマーサクセスエンジニアの井上です。

巷にあふれる「クラウドネイティブとは」という解説が、どれもなんか違うんだよなーともやもやしています (謎の上から目線)。
本家本元(?) は、Cloud Native Computing Foundation (CNCF) の Cloud Native Definition  だと思いますが、システムの構築・運用やクラウドについてある程度知見がある人向けにいい感じにまとめてくれているものの、もう少し手前の段階にいる方々が理解しやすい説明にはなっていません。
他のものも同様に、耳に馴染みのない専門用語で説明されていたり、いきなり特定の技術の話から始まったり、最悪は特定の技術を使えばクラウドネイティブになると誤解されそうな説明だったりします。

どの説明が正しいとか「俺の説明がサイコー」とか言うつもりも自信もまったくないのですが、この記事では少し違う説明を試みてみます。
なお、この記事の内容は、弊社の統一見解ではありません。社内でもいろいろな意見があり議論を続けています。そしておそらく、その時々の考えは持ちながらも、より良い考えを求めてずっと議論を続けると思います。この記事はあくまでひとつの参考になりましたら幸いです。

クラウドネイティブとは

クラウドの特性を最大限に活かすこと

そのまんまですね。こういうのでいいんだよ、こういうので。
ではその最大限に活かしたい 「クラウドの特性」 とは何なのか？

クラウドの特性とは

サーバーを「ソフトウェアによって」「短時間に」立ち上げられる

クラウド以前なら、発注して納品されて設置して配線して使えるようになるまで数カ月～数日かかっていたサーバーの立ち上げや CPU、メモリ、ストレージ、ネットワークなどのサーバーリソースの増設が、手もとの パソコンから操作するだけ で、数分から数秒 で、使えるようになった、ということです。

クラウドの特性を活かす

そうすると、これまではやりたくてもできなかったり、現実的ではなかったりしたことが、できるようになりました。

1. サーバーの立ち上げを自動化したい

   手もとのパソコンからの操作で立ち上げられるとはいえ、毎回手作業でぽちぽちしながら設定したり立ち上げたりしているのでは、間違いも起きますし、なにより めんどくs 手間と時間がかかります。
   そうではなくて、構成や設定をソースコードの形に書いておいて、それを食わせるだけで、指定した通りの構成と設定でサーバーが立ち上がるようにすれば、間違いが起きにくくなり、手間と時間も削減されます。
   さらに良いことに、ソースコードの形ならば、バージョン管理システムに入れて変更の履歴を残すことができるので、不具合があったときの原因調査や復旧が容易になります。

   こうして (かどうかは知りませんが) インフラのコード化 / Infrastructure as Code が誕生しました。

2. システムを更新したり設定を変えたりするときにゼロから綺麗につくりなおしたい

   本番環境のシステムを更新するのに、サーバーに乗り込んで手作業でインストールしたり設定を変更したり。ここでもやはり、間違いが起きがちですし、めn 手間も時間もかかります。 また、何度も更新に更新を重ねる間に、使わなくなった設定や構成の残滓を溜めてしまいがちで、そうすると、必要なものと不要なものの見分けがつかなくなり、安全に更新できなくなります。
   サーバーの立ち上げをコードで書けるようになったおかげで、更新のときも、新しい構成と設定でコードを書き換えてゼロから立ち上げ直しても大した手間と時間ではなくなりました。

   このやり方を 不変インフラストラクチャー / Immutable Infrastructure と呼んでいます。

3. 立ち上げてテストが通った新バージョンをそのまま本番環境の旧バージョンと差し替えたい

   サーバーをコードでゼロから立ち上げ、テストも通って本番適用というときに、本番環境でまたサーバーを立ち上げ直すと、いくらコードで書いてあるからといっても、環境の違いなどによって完全に同一にならないリスクは少ないながらも残ります。
   どうせなら、テストが通ったサーバーそのものを本番運用に移行したい。前段にリバースプロキシを立てておいて、旧サーバーから新サーバーに切り替えれば、それが可能になります。
   さらに良いことに、更新作業のためにシステムを止める時間をゼロにできますし、本番適用後に新サーバーに不具合が見つかったとしても、即座に旧サーバーに切り戻すこともできます。

   ブルー グリーン デプロイメント / Blue-Green Deployment は (たぶん) こうして生まれました。

4. 負荷が高くなってきたらその時点で処理能力を増やしたい

   クラウド以前は、需要予測などに基づいて負荷を予測して、予め処理能力を増強しておくしかありませんでした。しかし予測というのは外れるもので、予想以上に高負荷になって能力が不足したり、能力が余って費用だけが嵩んでしまったりしていました。
   数分～数秒でサーバーを立ち上げられるようになったので、実際に負荷が上がり始めてから能力を増強してもある程度間に合うようになりました。コードから全く同じ構成のサーバーをいくつでも立ち上げられるので、サーバー単体の能力を上げるよりも、サーバーの数を増やして負荷分散することがやりやすくなり、能力の上限も理論上なくなりました。
   また負荷分散だけでなく、同じ構成のサーバーが複数あるので、1台に何かトラブルがあって停止してしまっても、残りのサーバーでシステムは稼働し続けられますし、1台分下がった能力は、すぐに別の1台を立ち上げて補うことができます。

   これがいわゆる スケールアウト / Scale Out もしくは 水平スケーリング / Horizontal Scaling です。

5. 新バージョンは一部のユーザーに公開して問題ないのを確かめてから全ユーザーに適用したい

   水平にスケールアウトしたシステムでは、システム更新の際には複数のサーバーを更新することになります。
   どうせなら、全部一気に更新しないで、新サーバーに問題がないことを石橋を叩いて確かめながら少しずつ順に更新したらどうでしょう。もし何かあっても、影響範囲を小さく留めることができ、個々のサーバーをブルーグリーンデプロイメントしていれば、すぐに旧サーバーに切り戻せます。

   これには (いささか残酷な) カナリア リリース / Canary Release と名前がついています。漸進的リリース / Incremental Release と呼ばれることもあります。

こういったことをできるようになりたいか、あるいはその前に、こういったことがビジネスの生産性や価値を上げることに繋がるシステムなのかどうかが、クラウドネイティブを目指すかどうかの決め手になります。

クラウドの特性ゆえに必要なこと

一方で、これまでは必ずしも必要なかったことが、上で挙げたようなことをしようとすると必要になります。

• 適応性 / Adaptability

  ネットワークゾーンやクラウドプロバイダーといった複数の異なる環境でもサーバーを立ち上げられるように、サーバーの構成や設定から環境依存する部分を分離し、立ち上げ時にそれを外部から与えられるように設計する必要があります。

• 可観測性 / Observability

  前述した高負荷や不具合を迅速に検出する仕組みが必須です。そのために収集するログ、メトリクス、トレースといった情報は、サーバーの中に蓄積していると、不変インフラストラクチャーでは更新の際に消えてしまうので、サーバーの外に収集しておく必要があります。

上で挙げたクラウドで得られるメリットと、ここに挙げたクラウドゆえに必要になることの、両面を勘案してメリットの方が大きいかどうかを、クラウドネイティブを目指す際には判断する必要があります。

クラウドネイティブにしたい理由

ところで、さきほど「やりたくてもできなかった」と書きましたが、なぜそういうことをやりたかったのでしょうか。 整理してまとめ直すと、こういうことが言えます。

• システムの更新や設定変更を素早く、手間をかけず、かつミスなく行いたい
• システムの更新や不具合や過剰負荷によるサービス停止や低下をなくしたい
• システムに不具合があっても素早く復旧させたい

これらのそれぞれにも価値がありやる意義がありますが、これら全部を総合するとどうなるでしょうか。システムの更新や設定変更が、素早く、手間がかからず、ミスなく、サービスを停止せずにできて、万一不具合があっても素早く復旧できる、となるとどうなるでしょう？
システムをしょっちゅう、毎週や毎日どころか一日に何度でも、更新したくなりませんか？
もし不具合があったら、すぐに修正してその日のうちにも解決できるかもしれません。不具合を修正したら、機能は正しく動くようになったもののシステムの性能を落としてしまうかもしれません。しかしすぐにそれを検出して、さらに修正することができます。
なにより、機能の改善や、ビジネスのアイデアを、思いついたらすぐに適用して、反響を確かめることができるようになります。その結果をもとにさらに改良してすぐに適用することができて、日々変化するビジネス環境にシステムを迅速に追従させたり、システムを速く進化させることができます。

これが、アジリティ (俊敏性) / Agility と呼ばれる特性です。上で挙げたことがらが全て何らかの形でアジリティに繋がっています。クラウドネイティブで得られる一番のインパクトが、アジリティを手に入れることだと言ってよいと思います。

コンテナ、Kubernetes、マイクロサービス

最後に簡潔に触れておきます。

コンテナ、Kubernetes

コンテナや Kubernetes を使わないとクラウドネイティブではないということは全くありません。同様に、コンテナや Kubernetes を使うだけでクラウドネイティブになるということも全くありません。
「クラウドの特性を活かす」ために大いに役立ちますし、活用の程度をさらに大きくできます。その一方で、コンテナや Kubernetes を使う「ゆえに必要なこと」がさらに増えます。上でも述べたように、得られるメリットと追加で必要になることの両面を勘案して、メリットの方が大きいかどうかを、よく見極めた上で採否を判断する必要があります。

マイクロサービス

マイクロサービスも同様に、クラウドネイティブの必要条件でも十分条件でもありません。
クラウドネイティブには人的な側面も大きく関わりますが、マイクロサービスではそれが顕著になります。マイクロサービスとは、独立性が高く相互に疎結合な小さなサービスの集合体としてシステムを構成する方法です。「独立性が高く相互に疎結合」を平たく言うと「個々のサービスが独自の判断で勝手にいつでも更新することができる」ということです。そのため、アジリティをものすごく上げることができます。しかしそのためには人的なアジリティも合わせて備えている必要があります。例えば、各サービスが毎日10回更新できる能力を持っていても、更新に月例リリース判定会議の承認が必要なら月に1度しか更新できません。そういった人的側面もマイクロサービス採否の考慮に入れる必要があります。

おわりに ~ クラウドネイティブのゴールデンサークル ~

ゴールデンサークルという考え方があります。Why から始めて、How、What の順に説明すると他人の共感を得やすいというものですが、計画や戦略を考える際にも役に立つ考え方です。

なぜクラウドネイティブにしたいのか？
アジリティがほしいから？
なぜアジリティがほしいのか？
まずそのあたりから始めましょう。
How: 不変インフラストラクチャーや水平スケーリングはその次でいいのです。What: コンテナやマイクロサービスはさらにその後で。