と、今日ふと思ったので、その辺りを雑に書く。
1. その [Serverless は本当に必要ですか？]
基本的に、僕は [[AWS Lambda]] + [[Amazon API Gateway]] みたいなのは、
現代におけるモダンな CGI っぽいモノ
という認識でいるんだけど、基本的に、これらの [[Serverless ]] Architecture というモノの最大の利点は、
その Serverless なサービスを提供するプラットフォームのサービスを、 CGI っぽいスクリプトからシームレスに扱える
と言う所に有る、と今は思ってる。
そしてもし仮に、例えば、 [[AWS Lambda]] + [[Amazon API Gateway]] で Web Service を作るとして、 そこに AWS 固有の要素が無かったりするのであれば、これはもう普通に共有 ホスティング系のサービスで、 CGI + MySQL でサービスを作る、というのと、あまり違いがないのではないか、という考えに今日至ったんだけど、 何故そう言う考えに至ったかと言えば、
- [[AWS Lambda]] 等は基本プロセスを使い捨てる (はず) 即ち、これは CGI のあり方と近い
- Amazon API Gateway など HTTP Gateway は色々制約が有る その点も、共有ホスティングでの制約に近い
- マネージドなスクリプトホスティングは、共有ホスティングでも可能 とは言え、デプロイとかは工夫が要りそう
というのが、主な理由。
無論、これにはいくつかの条件の重なりは必要だと思うし、また、先に例に上げた、 [[AWS Lambda]] + [[Amazon API Gateway]] なプロダクトが有ったとしても、
- 消費リソース (メモリ等) が少ない
- プラットフォーム固有のミドルウェアを使わない
- デプロイが自動化可能である
という辺りの条件さえ満せば、
共有ホスティングでの実行も検討の一つの入るのはないか
と思います。
2. 共有ホスティングの障害点
先程、
条件さえ満せば、共有ホスティングでの実行も検討の一つに入る
とは言ったものの、
では、何が共有ホスティングでの実行における障害と成り得るか？
と考えると、僕としては、大体、
- 共有ホスティングのサーバの当り外れ
- デプロイの自動化
- アカウント管理
の三つが障害というか障壁になるのかな、と思う。
というのも、まあ昔レンタルサーバとか借りてた方なら判るかもしれないんだけど、 [[共有ホスティングサーバ]] は、同居する他の利用者が、過剰にリソース使ってたりすると動作が安定しなかったり、あるいは、サーバを Abuse してたり、あるいは脆弱性を突かれて Abuse の踏み台になってたりすると、その サーバの IP が何らかの [[ブラックリスト]] 入りしてたり、というリスクが有ります。
また、 [[デプロイの自動化]] と [[アカウント管理]] も似たような話なんだけど、基本、 [[共有レンタルサーバ]] の内、特に [[ビジネス利用]] が考慮されてない [[個人利用]] 向けだと、デプロイ手段が [[FTP]] とか、 [[SSH]] が使えないとか、あるいは、そもそそもアカウントマネージメント機能が無いとか、そういうケースも有り得ると思うので、その辺りも、モダンな権限管理とかしている組織なんかでは、 結構気を使わないとダメなところだと個人的に思うし、あと、SSH 使えない + ライブラリや実行環境を自前でコンパイル出来ない、という環境だとかだと、そもそも [[Serverless]] アーキテクチャの代用とかには向かないと思うので、そう言った点も気を付けるべきだと考えてます。
それと、大量のアクセス数を捌き切れるのか、という問題も有るには有って、例えば、データストアへの大量の読み書きが存在するスクリプトは流石に 共有ホスティングには向かないだろうし、また、ファイルシステムも高速じゃないと……みたいな要件には、まあサーバのスペックに依るだろうけれど、あんまり 共有サーバは向かないと思う。
ただ、大量のアクセスと言っても、例えばこれが Read-Only な静的ファイルへのアクセスだったり、一度生成すれば大丈夫なコンテンツだったりするのであれば、普通に CDN 使えば良いだけの話なので、この点では、共有サーバを使うのも、あるいは Amazon S3 の Web Hosting 機能使うのも大差無いと思います。まあコスト面での違いは有りますけどね。
3. 使い分けとかその辺りの話
まあ、ぶっちゃけ
[[Serverless]] な platform を使う / 共有サーバで何とかする
というのは、本当にケースバイケースだと思うし、また、そのプロダクトが要求する要件や予算にも依る話だと思うので、 その辺りは本当に良く良く検討して決めた方が望ましいと思うのだけども、Serverless なアーキテクチャも向き不向き有ると思うので、まーそれも銀の弾丸ではない、とは思っておいた方が良いと思います。
ただまあ、例えば、
とかだと、RS2 Plus は共有サーバで有りながら永続プロセスとかも使えるし、また、利用料金も VPS っぽい感じで必要な時だけ使う、みたいなコトも出来るので、そう言った意味では、 [[Gehirn Infrastructure Services]] みたいなホスティングサービスが増えて来れば、
Serverless アーキテクチャを使うにはちょっと向かないし、かと言って、 VPS を使うのはちょっとオーバーだし……
みたいな案件は、
とりあえず GIS っぽいの使おう
というのが出来る様になるのではないか、と思います。
ま、とは言え、 [[Gehirn Infrastrucrure Services]] とか、(個人的には) そんなに安くはないですけどね。
以上
なんか雑に書くつもりが、思った以上に文章量が膨らんでしまいました。どうしてこうなった！どうしてこうなった！あと一応最後に言っておくと、今回の記事、 Serverless アーキテクチャを Dis ってるつもりは微塵もなく、
[Serverless アーキテクチャという面白げなシステムだけに発想が囚われていると、他の選択肢が見えなくなったりするよ！]
という感じの話しでも有るし、また、現実に 僕はそういう面に囚われてしまっていて 、そうした、
[[Serverless]] アーキテクチャは無闇やたらと使おうとするの、マズくね？
という思いも有ったので、今回、こういう記事を書いたりしたのでした。ま、この記事を書いたのは、思い付きの考えを言語化して整理する、という意味も有りますが。
という事で思い付きで書きは始めて、思ったより長くなった記事は以上です。はい。
