IaaS各社が提案しているクラウドコンピューティングの次。
この記事は
Makuake Development Team Advent Calendar 2019 Day.1
の記事です。
クラウドコンピューティングリソースを提供しているIaaS大手といえばAWS・GCP・Azure・Alibaba Cloudですが、各社、一通り従来のOSベースでのアーキテクチャ構築インターフェースを提供し終えた後に、各社思想を色濃く反映して次世代バージョンのインターフェースを提供し始めています。
そうした「クラウドコンピューティングリソースへのアクセス」という観点での各社の違いを、今回はAWSとGCPを例に取り上げて解説します。
汎用ミドルウェアのmanaged I/Oを用意するAWS式
AWSが最初にとった戦略は、LB・ElastiCache・DynamoDB・Auroraに代表される、それまでインスタンス上でmemcached・KVS・MySQLなどを立ち上げることによってアーキテクチャの一部として組み込んできたサービス内の各機能を、managed I/Oとして提供することです。
これによって、アプリケーション開発者は各ミドルウェアのパフォーマンス設計について気にしなければならない機会が劇的に減りました。クラウドIaaSの利用者はほぼ誰でもが恩恵に預かり、感動したことでしょう。
lambda系のサービスはAWS I/Oを基軸としたコンピューティングリソースの最適化戦略の要となるサービス群。
近年では「Serverless」シリーズとして展開。
AWSは、そうしてmanagedな状態で用意したコンピューティングリソースに対して、ハードウェアのように常に起動（CPU/RAMリソースをアクティブに）しておいて、応答を返すインターフェースも用意していますが、lambdaのように起動時にのみリソースをアクティブにするインターフェースを用意しています。
lambdaはリリース当初は限られたプロゴラム言語を動作させるためのtmpリソースとしての活用しかできませんでしたが、段階的に LBの下に配置してEC2のように動作させたり、Step fuctionなどで、段階的なリソース計画が必要な処理にも対応しました。
さらに、AuroraにもServerlessインターフェースが登場し「使った分だけリソースを消費」というスタイルをメインストリームにしようという思想を持っています。旧来からあるS3などのCDNや、CloudFrontなどのCached Gatewayも同様です。
その他、AWSのServerless Computingページには、AWSのクラウドコンピューティングリソース活用戦略の肝となるサービス群が紹介されています。
ここを読めば、AWSがDynamoDB以降、Lambda、Aurora、といったクラウドコンピューティングリソースとそれにアクセスするServerless I/Oを段階的にリリースしてきた思想や背景が窺えます。
AWSはAuroraのリリース時にかなりのリソースをAuroraに投下していました（年間の予算規模が当時もう一端の完成を見ていたDynamoDBとは比べものにならなかった）。その結果、Auroraのパフォーマンスはリリース当初から数ヶ月の間で芸的に改善しました。このことからも鑑みるに、AWSは大きな思想に沿った機能には集中的に開発資源を投下する傾向があるので、今後も AWSをメインIaaSとして使っていくのであれば、この流れに剃った使い方がコストの面でもパフォーマンスの面でも優遇されていくでしょうし、恩恵を得られることになるでしょう。
GCPは無限LBを基盤にContainer、Kubernetesベース。
列指向型とデータサイエンス、も活用の肝。
対してGCPは、OSのようなコンピューティングリソースの一部（というにはあまりにも大きな割合）を食うオーバーヘッドの存在を嫌う立場をとっているせいか、初めからMySQLのような旧来のデータストアをエミュレートするような戦略は取らず、Dockerをはじめとするインスタンスそのもののオーバーヘッドを削減するような技術に開発リソースを投下してきました。
加えて、Googleの運用実績に裏付けられた無限にスケールすると言われるLBも、GCPの各種インフラを支える重要なファクターとなっています。
※ AWSのLBはあまりに急激なアクセスリソースの変化にはウォームアップと呼ばれる準備が必要ですが、GCPのLBにはウォームアップという概念はなく、デフォルトのまま水平に（現実的には）どこまでもスケールする。
また、データストアに関しては高いSLAを求められるエンタープライズサービス向けには列指向型のSpannerのみをインナップしており、エンタープライズは軒並みこれに合わせてアーキテクチャを設計するように、とのメッセージが見て取れます。
従来からのRDBMSはElephantSQLなどのサードパーティに依存するか、containerベースのMySQLなどを運用することになり、この点は現実的には既存システムのシンプルな意向を妨げる代表的なファクターになっています。
Googleがkubernetesエコシステムに賭けた思い
よく「エンジニアはなんのためにkubernetesを使うべきか？」という論があります。kubernetesはContainerベースのエコシステムから発生・進化した非常にクールなコンピューティングリソースI/Oであることには変わりありませんが、旧来のシステム・アーキテクチャの構築概念とあまりにも違いすぎて、ここに「流行りの技術を追うべきだから」というミーハー（ではないとは言い切れないよう）な答え以外の合理的な返答を見出せずにいるエンジニアは少なくないと思います。
しかしAWSがかつてベースに採用していたXen（第5世代c5系からKVMに移行）と違い、当初からKVMベースで今も最適化を続けられているGCP自慢のCompute Engine VMの設計には、GCPでkubernetesを使うべき大きな理由が記されています。
100台のコンピューターを「1つの大きなコンピューター」として取り扱うため
GCPとkubernetesは100台のコンピューティング・リソース・コントロールでは「100台あるコンピューターをどう使うか」ということを念頭におきません。
詳細な解説は本が一冊書けてしまうほどの分量になるので割愛しますが、基本思想は「100台分を一塊にしたコンピューティングリソースをどう活用するか」です。
kubernetesのコンピューティング・リソースへのアクセスI/Oは、そのほとんどがそうした「塊として再定義したコンピューティングリソース」へアクセスするのに最適化されています。 100台で200台に匹敵するようなコンピューティングリソースを実現する、というようなのが、当初のKVMの思想であり、それがそのままGCP・kubernetesの思想にもなっています。
その思想に対し、AWSは「マネージドなミドルウェアに対してServerlessアーキテクチャで必要な時だけリソースをアクティブにして消費する」というスタイルを提案しているのに対し、「Cloud Computerのような巨大なコンピューティングリソースにアクセスするI/Oは今まで存在していなかったので、新しく作ったのだ。それがkubernetesだ」というのがGCPスタイル。
つまり、コンピューティングリソースへのアクセスの仕方が全く違うのです。
結果として全く同一のhttpインターフェースをもつWEBアプリケーションを AWS・GCP上で作成したとしても、そのアーキテクチャをどんなに似せたとしても、コンピューターサイエンスの観点からすると、全く異なる処理の仕方をしているのです。
また、そんな理想ベースの競争の話ばかりしていても仕方がないので、もう少し実用的な話をしましょう。
最近はkubecon 2019 NAでGraduationに昇格したVitessのようなMySQLをスケーリングするソリューションが生まれつつあります。これはRDBMSのスケーリングがネックでどうしてもシンプルな移行ができなかったアプリケーションのGCPへの移行を手助けするかもしれません。
こういったこと「コンピューティングリソースへの理想のアクセスI/Oは用意するので、それを活用した既存のミドルウェアの概念にとらわれないアーキテクチャ設計を一緒に考えよう」というメッセージをエンジニア業界に投げかけています。
そうした試みは、
・ハードウェアあたりのコンピューティングリソース提供量を劇的に改善する可能性がある
・コンピューティングリソースを提供するハードウェア設計にも影響を及ぼす可能性がある
という点だけでも掛け値なしにクールです。
ただ、GCPに我々のサービスを預けるということは、少なからずそういった実験的なプラットフォームと運命を共にするという話になりますから、相応の覚悟と熱量が必要です。
まとめ
・AWSのサーバレス戦略
・GCP＋kubernetesのコンピューティングリソース再定義戦略
これらはどちらもLinuxサーバー・インスタンを中心とした既存のアーキテクチャ設計思想とは異なるものですが、従来のサーバー設計から、巨大なコンピューティングリソースの一部をどううまく間借りするか、という形への考え方のシフトは今後どのCloud IaaSを利活用するにあたっては必要不可欠な考え方になってきます。
言い方を変えれば、各社がいよいよ「クラウドコンピューティングの利活用へ、シフトを一段上げた」と言えるでしょう。
仮想通貨のマイニングがエネルギーを膨大に消費していると警鐘が出たことが示すように、未来「膨大なコンピューティングリソースがエネルギーを食い潰す存在」になる可能性は否定できません。
そうした未来を現実にしないためにも、世界のIaaSは各社の思想に基づいてクラウド・コンピューティングを再定義しようとしているのです。
あなたの作っているアプリケーションは、どのような思想に乗りますか？
-----
Makuakeでは、一緒に働きたいエンジニアを募集しています。
エンジニア募集！応援購入スタイルを提案するMakuakeを共に開発しよう！