こんにちは、@Keisuke69 です。
ポエムです。
クラウドネイティブとサーバレスアーキテクチャと言うものに関してなんとなく整理がてら書きたいなーと思って。
ま、この2つを一緒に話すのはどうなんだって気もするがポエムなので気にしない。あと文章長い割りに大して中身はない。
クラウドネイティブ
そもそもクラウドネイティブとはなんなのか。クラウドネイティブって言葉が先行していて実際のところなんなのか分からない人も多いはず。何かきちんとした単語の定義があるかっていうともちろんそんなのあるわけない。人それぞれモヤっとしたイメージがきっとあってそれを一言で表現するのにクラウドネイティブってキーワードが使われてるのかなと。ラベリング重要。
とはいえ、クラウドネイティブというお題で僕が話をするときに毎回最初に定義をしていて、その定義は以下の通りだ。
こうやって見ると1つ目はクラウドネイティブというよりも、この用語が出てくるちょっと前に使われていた（今も使われている？）クラウドファーストの定義に近いかも知れない。うん、これは今後は外そう。で、一番大事なのは2番めのやつだと思っている。
まず、最近誤解されている気がするのであえて言っておくとクラウドネイティブそのものはAWSネイティヴとは違う。混同されがちだし、あえて同じコンテキストで話がされていることもあるが本来はそもそものコンテキストが違うのだ。そんなのわかってるよって人は読み飛ばしてくれて構わない。
AWSネイティブはその言葉通りAWSの各サービスをフル活用してアプリケーション開発することでスピードとスケールを手に入れようという話である。一方クラウドネイティブはサービスとして提供されている機能群を有効活用するのというのもあるが、根本的にはクラウドだからこそのスケーラビリティや俊敏性を活かして分散的にシステム構築することでレジリエンシ高くスケーラビリティの高いシステムを作ろうということだと思っている*1*2
広義のクラウドネイティブにはAWSネイティブも含まれるかも知れないが先述のとおり本来はコンテキストレベルの違う話だと思っている。したがってAPI GatewayとLambdaを使ってサーバレスアーキテクチャにすることがクラウドネイティブなのではない。クラウドネイティブの本質はレジリエンシとスケーラビリティをいかに高めるかだと思っていて、そのためのシステムおよびアプリケーションのアーキテクチャの話なのだ。このシステム、アーキテクチャ面での考え方自体はクラウド以前からあったと思うし、考え方そのものはサーバが物理だろうが仮想だろうが関係ない。ましてやそこにサーバがあるかないかなんて大事な話ではない。ただ、それがクラウドの登場により実現に現実味が増したと言えるということだ。ようやく誰でも実現可能になったと言ってもいい。従って旧世代のシステムをそのままの構成で単にクラウド上にマイグレーションすることはクラウドネイティブとは呼びがたい*3
広義のクラウドネイティブにはAWSネイティブも含まれるかも知れないが先述のとおり本来はコンテキストレベルの違う話だと思っている。したがってAPI GatewayとLambdaを使ってサーバレスアーキテクチャにすることがクラウドネイティブなのではない。クラウドネイティブの本質はレジリエンシとスケーラビリティをいかに高めるかだと思っていて、そのためのシステムおよびアプリケーションのアーキテクチャの話なのだ。このシステム、アーキテクチャ面での考え方自体はクラウド以前からあったと思うし、考え方そのものはサーバが物理だろうが仮想だろうが関係ない。ましてやそこにサーバがあるかないかなんて大事な話ではない。ただ、それがクラウドの登場により実現に現実味が増したと言えるということだ。ようやく誰でも実現可能になったと言ってもいい。従って旧世代のシステムをそのままの構成で単にクラウド上にマイグレーションすることはクラウドネイティブとは呼びがたい*3
加えて、クラウドネイティブなシステム作りをドライブするためには（開発における）ユーザ体験も非常に大事だと思っている。クラウドネイティブだかなんだか知らないけど開発する上ではやっぱり楽なほうがいいよね、と。ローカルで開発してクラウド上にアップするというのが今の多くのスタイルだと思う。もちろん実際にはCI/CDなりのプロセスや自動化なんかが間にはあって、各個人が直接ローカルから都度アップロードしているわけではないと思うが、そういった自動化だとかがアプリ開発者に意識させずに使えるようになると真のクラウドネイティブな気がするな。あとはレジリエンシを高めるためにはモニタリング必須になってくるのでその辺りとかも組み込まれてるといいね。そういう意味ではアプリケーションフレームワークとの密接な関連性、透過的なクラウド利用なんかが求められてくるのかも知れない（適当
サーバレスアーキテクチャ
この言葉自体はそれまでにもあったとは思うけど僕がこのキーワードを使いだしたのはそう、あれはAPI Gatewayがローンチされてからだ。それまで僕は2 Tier Architectureというものをいろんなところで語っていた。2 Tier Architecture自体はここでは触れないが、それ自体はいいと思っているが採用できる局面は限定的と言える。なぜなら2 Tier Architectureを採用した場合、ロジックをクライアント側に持ってくる必要があるからだ。クライアント側にロジックを持ってくると何が問題か。問題の1つとしてマルチプラットフォーム対応があげられる。これが面倒なのだ。各プラットフォームごとにUIに関する部分以外のロジックを実装しなくてはならなくなる。同じ内容を違う言語で、だ。当然、テストコードもそれぞれ必要になるからそれがどれだけ大変なことかは想像に難くない。そこでロジックはサーバサイドに持って行って共通化しよう、そしてその処理はアプリからAPI経由で呼び出そう、となる。そうすると今度はサーバサイドのロジックを書くだけでなくAPIとして公開するためのインフラの構築・運用が必要になってくる。そんなわけでこの辺りから2 Tier Architectureじゃなくなる、というか限界が見えてくる。採用できる局面が限定的としたのはこういう理由からである。ハマれば絶大的な効果があると思うが、そうでない場合は従来どおり3 Tier*4なシステムを、と言っていた。
この時点で元来チームにフロントエンド系のエンジニアしかいない場合には絶望的だ。そもそもクライアントにロジックを持っていく判断をしたチームにインフラエンジニアがいるとも思えない。そこで出てくるのがサーバレスアーキテクチャである。AWSで言うと、Amazon API GatewayとAWS LambdaおよびDynamoDBとかを組み合わせたものをよく例として挙げているがこれはサーバレスアーキテクチャの一例に過ぎない。別にLambdaを使うからサーバレスだとは思わない。平たく言うとマネージドサービスを使うことで（ある一定範囲までは）楽をするモデルなのだ。これまで自分で構築して運用してきたサーバ群の代わりにサービスとして提供されるマネージドサービスを必要に応じて、必要な分だけ、必要なときに使うのがサーバレスアーキテクチャだと考えている。従ってフルサーバレスなアーキテクチャにできる場合もあれば一部がサーバレスな場合もあるかも知れない（というかそのほうが多いだろう）。あちこちでサーバレスアーキテクチャの考察的なものも見受けられるが、そんな大層なものではなくってぶっちゃけた話、ユーザの視点から見てユーザが自分でお守りをしなければいけないサーバ（インフラ）があるかないかってだけじゃないかな。少なくとも僕はそう思って話をしている。だからインフラの構築・運用にかかるコスト（これには当然それらを担当するエンジニアを抱えるコストも含まれる）や仕様面を比較した上で任せられるなら任せてしまえばいい。マネージドサービスを有効活用することはとてもいいことだと思うがそれに縛られるのは本末顛倒だ。本来あなたがやりたいことは何なのか思い出して欲しい。とはいえ、サーバレスアーキテクチャとはそうではないと思う人がいたらぜひディスカッションしたいです。
最後にクラウドネイティブとサーバレスアーキテクチャってタイトルなので両者の関係について言うと、サーバレスアーキテクチャを実現するクラウド側のサービス群はクラウドネイティブに作られてるだろうけどユーザが作るクラウドネイティブなシステム＝サーバレスアーキテクチャではないかなっと。
あ、一応免責つけておこうw
本ブログは個人としての意見であり所属する企業や団体を代表するものでも見解を示すものでもありません。
