オンプレで構築されたシステムをクラウド上にリフトする案件ではなく、最初からシステム基盤としてクラウドを前提に構築するシステムのインフラ設計をしていて、ふと「クラウドネイティブ」って何だ？と思い、以下のエントリを執筆します。
クラウドネイティブの定義
いろいろ調べてみたのですが、どうも因果がおかしなことになっている感があります。
「マイクロサービスで作るのがクラウドネイティブ」であったり、「コンテナ環境の利用したアプリケーションがクラウドネイティブ」なんていう、「クラウドサービスを前提」とした設計を行った「結果」をクラウドネイティブと説明していて、なんかおかしいぞという気持ちがします。
クラウドネイティブは、そのまま「クラウドサービス利用を前提とした」設計であったり、その結果のアプリケーションやシステムだと考える方が自然だと思います。
さて、皆さんが興味のあるのは、実態として「クラウドネイティブ」になると、何が変わるんでしょうか？
その前にクラウドとオンプレの違いを振り返りましょう。
クラウドとオンプレの違い
オンプレでシステムを構築する際、システム構成を決定して、上に乗せるアプリケーションのソフトウェアスタックを決定し、耐用年数や想定トランザクション、可用性なんかを想定して、サイジングやらハードのスペック設計します。
この際、高い可用性が求められれば、サーバやストレージが故障してもサービスが継続できるようハードを冗長構成やホットスペアで部品が交換できるようなハードを検討します。いわゆる商用UNIXの上位機種やFTサーバ、メインフレームなんかが候補ですね。
つまり、高い可用性やら性能をハードに依存することが可能です。
これがクラウドになると、クラウド事業者が用意するコンピュート資源やストレージ、サービスのSLA以上の可用性は設計できません。
そりゃそうですよね。提供側が99.95%っていったら、それ以上の可用性はムリですよね。
そう、クラウドとオンプレの違いとして、サーバやストレージといったリソースの可用性を単体で高める方法がないわけです。
クラウドでどう作るか？
じゃあ、どうするのか？
止まっても大丈夫なように作るんです。
一部が止まっても全体に影響が出ないような設計が必要になるわけです。
また、その他に止まっても早期に復旧することでサービスの停止時間を極力短くして可用性を上げる戦略も有効です。
ここまで読んでみて、何か気づきません？
止まっても大丈夫にするなら、サーバを並列動作させて、１台故障しても他のサーバでサービス継続させる。
AWSでELBを利用して、複数のサーバでリクエスト処理を受け付ける設計。
止まっても早期にサービスを起動させるなら、OSから起動させると起動までのオーバヘッドが大きいからコンテナにして、動かすアプリケーションも小さい方がいいよね。
OS上での動作からコンテナ上での動作に移行。
アプリケーションを小さくにするには、業務ドメイン単位に分割するのが自然。
小さなアプリケーションが協調して動作する環境って、「マイクロサービス」っていうんじゃない？
というように、クラウドで高可用性アプリケーションを作る戦略として、コンテナやマイクロサービスが必要になるのであって、その逆ではないんです。
この方向性がクラウドネイティブの一面なんじゃないかと思います。
まぁ、この他にも運用を便利にするために極力マネージドサービスを利用するといった話もあるんですけど、それはまたの機会に。
どっとはらい。