サーバレスに関して調べたこと
サーバレスというキーワードについて、一度しっかり調査しておきたいと思い、 調べたことをまとめてみた。
自分は基本的にクラウドサービスはAWSしか知らないのでところどころAWSを意識した記述になっていると思いますが悪しからず。
サーバレス概要
- FaaS(Function as a Service)、およびその他のマネージドサービスを組み合わせて構築されるシステムのこと
- 開発者目線でサーバーが隠蔽されるので、サーバーレスと言う
- AWSで言うと、Lambda(FaaS)、S3(ストレージ)、DynamoDB(DocumentDB)、Cognito(認証)、API Gateway(APIプロキシサーバ)、SQS(メッセージング)、Kinesis(大量データストリーミング)、などのサービスで構成されるアーキテクチャ
- 各サービスが動作するサーバ自体はサービス内に隠蔽され、クラウドベンダ側が運用保守を請け負う
自分のイメージ
- インフラ管理から解放される
- Infrastructure as Codeをサービスに組み込んだイメージ。最初からリソース操作がコード化されているから、勝手にImmutable Infrastructureになる
- 結果的に、インフラはステートレスとなる
- マイクロサービス的になる
- FaaSが提供する機能が小さい単位になるので基本がマイクロサービス的設計に落ちていく
- コンテナ環境と比較はされるが、コンテナのサーバーレスサービス使えばお互いのメリットを活かせる気がする
- 下回りがコンテナでもマネージドサービスでも、開発者目線で見たらサーバーレスに違いない
- 主にモバイルアプリ開発の文脈で聞くことが多い気がする(mBaaSは基本的にサーバレスだからかと)
サーバレスのメリット
記事後半の参考にした記事をもとにまとめたサーバレスのメリット。
- コスト削減
- 基本的に利用した分だけの課金になる。待機状態には課金されない。
- スケーラビリティ
- 特段の設定などしなくても、負荷に応じてオートスケールする。
- とはいえいろいろ考慮することはあるはず、と思う
- 特段の設定などしなくても、負荷に応じてオートスケールする。
- フルマネージド(管理不要)
- いわゆる従来の「インフラ管理」が不要となる
- 監視、アップグレードやパッチ適用、性能・拡張性担保、アプリ以外(ミドルやOS層)のログ管理、あたりは不要となる。
- 依然として必要なのは、セキュリティ管理
- 考え方が変わるのは、ログ管理(サービスのログを管理する)、性能担保(ボトルネックがどこかわかりにくそう)
- いわゆる従来の「インフラ管理」が不要となる
サーバレスのデメリット
自分が実際にAWSでおもちゃアプリを作ってみて感じたことも含む。
- 管理する対象が多くなる、散らばる
- システム構成要素が散らばるので、サーバーレス向けサービスの構築自体もCode管理するなどして管理しやすくすべき(当たり前か
- コードやアーキテクチャがベンダ依存になり、個々のサービスについて知識が必要
- 何の要素技術をどうマッピングしたサービスなのか把握して、設定方法を学ばないといけない
- セキュリティ(アクセス制御)を考慮する場所が増えて煩雑
- 各サービスの繋ぎ方がベンダ依存だったりするので、セキュリティ設定の方法もベンダ依存だったりする
- セキュリティ(アクセス制御)の実装方法がベンダ依存になる
- デバッグしにくい
- マネジメントコンソールをぽちぽちしながらは開発したくない
- インフラコードも合わせて書いて、どかんとデプロイしたい
- ローカルでもある程度はテストできるといい
- AWS SAM CLIなど、ローカル開発できるツールもあるっぽい
- 設計とテストをどうやるべきなのか、あまり想像つかない
- システムのできることがサービス仕様に縛られるのにどこか不安を感じる
- 今は動くけど、この先やりたいことが増えたとき、同じサービス上でできるのか?
- 自前コンテナで動かしている分にはやればできることが多いと思うが
参考にした記事とサマリ
- サーバレスの流れは、インフラのお守りにかけるお金よりアプリ開発のお金を重視する流れにより発展してきた。
- システムインフラのお守りのコストは30〜40%あり、サーバレスならそれが削減できる。スケーラビリティもインフラではなくアプリの設定としての関心事となる。
- コンテナとサーバレスの比較
- コミュニティの違い:コンテナはインフラ管理、サーバレスはアプリ開発の話題が多い
- サーバレスの特徴
- 個々のサービスのリソース制限が厳しい
- そのため機能単位が小さく、従来のモノリシックなシステムの複雑なロジックを実装するのは困難が伴う
- 個々のサービスのリソース制限が厳しい
- サーバレス導入にあたり
- コンテナオーケストレーションツールとしてはk8sがほぼデファクトとなった
- コンテナ実行環境のサーバーレス化が進んでいる
- podレベルでのサーバレスを実現するKnativeやOpenFaaS,Kubeless,Osiris
- ノードレベルでのサーバレスを実現するVirtual Kubelet
- podがオートスケールしても、下回りのノードがスケールしないと、結局サービスの起動時間が仮想マシンの起動時間ほどかかってしまう
- ノードをサーバーレスで提供するServiceを各クラウドベンダが提供している
- これらのサービス上でk8sを使えるようになってきていて、始まった感がある
- サーバーレスの基本的なメリットは、コスト削減とオートスケール能力であり、ことスタートアップにとっては本来魅力的である
- しかしサーバーレス関連サービスを駆使して適切にシステムを構築することは、自前でOSSなどを使って実装するよりも技術習得コストが高くなるケースがままある
- そのため多くのスタートアップは初期にそのようなコストを避ける傾向があるのは当然である
- ただしサーバーレスコンピューティングサービス(AWSにおけるLambda)やそれに類するマネージドサービス(AWSにおけるCognitoなど)を使う利点には、自前で保守する必要のあるコード(技術的負債)を減らす効果もある
- 開発チームを最適化するのに許される期間が月〜年単位なのであれば、サーバーレスアーキテクチャで準備することにメリットがある
- サーバーレスは「プロビジョニング、スケーリング、管理が不要」な特長をもつコンピューティングリソースのことである
- 従来はFaaSを指すことが多かったが、最近サーバーレスな特長をもつDBやコンテナ実行基盤のサービスも現れ始めた
- サーバーレスという言葉は、FaaSだけでなく「プロビジョニング、スケーリング、管理が不要」な特長をもつコンピューティングリソースのことを指すように改めて認知され始めるのではないか
まとめ
- 開発者目線で、アプリ開発に集中できるインフラの形態がサーバーレスアーキテクチャ
- 比較対象は、仮想マシン環境、コンテナ環境
- 近年DBやコンテナにも用途が広がってきており、今後も適用できる範囲は広がっていくだろう
- メリットも大きいが、デメリットも大きいので、導入先プロジェクトに向いているかは慎重な判断が必要
最近、GCPのCloud Runがなにかと話題なので、そのうち調べたいと思ってる。