クラウドネイティブとは

IT界隈で使われている用語で、正しく使われているものもありますが、適切な解釈をせずに使われている言葉もあります。全てに共通するのですが、それらが誤用される一因として「概念」を示しているからだと思います。「概念」を「手法」や「ツール」と解釈することで違う意味を持ってしまって、結局「良くわからない」という状態になっていると思うんですよね。
今日はその中でもモヤモヤする「クラウドネイティブ」という言葉に注目してみたいと思います。

クラウドという環境が出てくる前は、オンプレミス（物理的なサーバを自社もしくはデータセンターなどで抱えている環境）にてシステム、アプリケーションを構築・運用していました。分散していない環境下であるために、アプリケーションを構築すると、自在なアーキテクチャや手法で行っても特に問題なくプログラミングが可能でした。問題となるところでいうと、

• 業務拡大に伴う処理能力の増強には、マシン自体をスケールアップする必要がある

• アプリケーションがモノリス化しやすく、改修を重ねていくにつれ、軽微な修正でも多大な工数と費用が掛かるようになる

• マシンやVMが増えすぎて、管理しきれなくなってくる

• 災害時に全国の業務が停止する可能性がある

等が上げられます。
そこで「クラウドに持っていけば解決するのでは？」となるわけです。
クラウドに持っていくことで、

• CPUやメモリを追加できるのでスケールアップではなくスケールアウトで処理能力を上げられる

• アプリはそのままクラウドに持っていけば良い

• 「マネージド」と呼ばれる管理機能が付いたクラウドを選択すると、管理をお任せできる

• 災害時にはクラウドの別のリージョンで立ち上げればよい

と、低コストで課題解決できる... ように思えます。
しかしです。
殆どのお客様で、クラウドに持っていってから重大なことに気づきます。

データベースは他のシステムでも使っており、
「DBサーバはオンプレのままアプリだけクラウドに持っていったため、処理能力が格段に落ちてしまった」

そうなのです。クラウド環境に今までの作りのアプリを持っていっても、そのままでは解決しないのです。特に、アプリの中でで判断をDBのテーブルを参照しているもの、DBのロック機構に強依存したアプリは、そのままクラウドに持っていくと、クラウド上のアプリからオンプレへのDBアクセスが、処理遅延の最大の原因になります。オンプレミス環境では高速なネットワーク環境の為意識しなかった部分です。私が見たものでは、１処理に200回ものSQLが発行されていました。そりゃ遅くなります。パブリッククラウド環境だと通信量も掛かってくるので、お金もより一層掛かってしまいます。

では、どうすればよいのか？
クラウドに持っていく前に、クラウド環境に適したアプリの構造にすることが必要なのです。データ・ロジック・画面等の役割を分担し、互いを疎結合化したアーキテクチャにする必要があります。こちらのマイクロサービスアーキテクチャで説明しているように、役割（サービス）を連結して一つの処理を行う形にすべきであり、なるべく非同期化されることが望ましいです。

このようにクラウドに持っていってもそのまま動く状態になっているアプリケーションのことを、「クラウドネイティブである」と言います。そして、「クラウドネイティブ」なアプリケーションをクラウドに持っていくことで、より便利なツール（例えばコンテナ環境）の利点をもっと享受できるようになり、更に効率の良い仕組みが出来上がるのです。

残念ながら、日本のみならずグローバルにおいても、「クラウドに持って行くには"Lift & Shift"をまずやるべき」という論調が見受けられますが、即刻止めるべきです。やるなら、最初にアプリの構造改革を行い「クラウドネイティブ」な状態にしてからクラウドに移設する、いわば"Shift & Lift" にすべきなのです。クラウドでコンテナ化して大成功を収めている海外のお客様は全て、全て、"Shift & Lift" です。"Lift & Shift"では、クラウド環境にLiftしただけで数多くの問題が噴出し、その対応で終わってしまっています。

クラウドやコンテナにしたいと思うのなら、その上で稼働するアプリケーションの構造を確認してください。DB強依存・バッチ稼働のようなアプリであれば、まずは構造改革をし、「クラウドネイティブ」にしてからにしてください。更に、その際に「既に使っていないロジックやデータ」の断捨離をすることも強くおすすめします。ルール駆動開発がそのお手伝いができるのを確信しています。