この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
サーバレス
はじめまして。Game Server Services 株式会社の丹羽一智です。
今回はサーバレスで変わるサーバ開発の未来というお話です。 まずは、『サーバレス』とはなんぞや？というところから整理したいとおもいます。
サーバレスは去年の後半から話題になり始めたワードで、EC2をはじめとした IaaS とは異なり、OSやプロセスの管理が不要となる技術を指します。 まだ言葉の定義がしっかり固まっていないところがありますが、以下のような技術を総称してサーバレスと呼ぶ。と考えるといいのではないかとおもいます。
- FaaS (Function as a Service)
- PaaS (Platform as a Service)
- Functional SaaS (Functional Software as a Service)
FaaS (Function as a Service)
去年からサーバレスという名前を背負って火がつき始めた技術は この FaaS になります。
AWS の Lambda を代表としたサービスで、『S3 にファイルが置かれたら〜』『API Gateway に HTTP リクエストが届いたら〜』 といったイベントをトリガーとして
あらかじめ AWS に登録しておいた関数を実行できる。というサービスです。
PaaS(Platform as a Service)
PaaS の歴史は古く Google App Engine や heroku のようなサービスです。
FaaS との違いがよく議論になりますが、マーティン・ファウラー氏の Serverless Architectures では リクエストに対して起動し 500ms 以内に終える処理を20ms以内に起動できるのであれば、それは FaaS だろう。と定義されています。
GAE や heroku は 起動時間に関して満たせたとしても、500ms 以内にインスタンスが終了するようなことはなく、もっと長い生存期間を持ちます。
Functional SaaS (Functional Software as a Service)
PaaS や FaaS は自分で作成したプログラムをデプロイして利用するサーバレスサービスですが、Functional SaaS はフルマネージドサービスで関数を呼び出すように利用できるようなSaaSを指します。最近では BaaS(Backend as a Service) とも呼ばれたりします。
具体的には、弊社(Game Server Services)のサービス や AWS の Cognito、Auth0 のようなサービスを指します。
いずれも共通する特徴として、OSやプロセスについて考える必要がなくなり、サーバの死活監視のような業務が不要となる。ということがあります。 アプリケーションエンジニアでありながら、インフラ保守もしている。というような立場の方からすれば、こういった環境が整ってくるのは望ましいこと。という印象があるのではないでしょうか。
サーバ開発のこれまで
サーバレスとはなんぞや。というところがまとまったところで、これまでのサーバ開発を振り返ってみようとおもいます。 これまでのサーバ技術は以下のような変遷を遂げてきました。
- オンプレミス
- 仮想化
- IaaS (Infrastructure as a Service)
- コンテナ
オンプレミス
オンプレミスはハードウェアを購入し、サーバにラッキングして、配線をして…。というような世代です。
ハードウェアの調達には数週間〜数ヶ月を要するようなことも珍しくなく、アプリケーションのベンチマークを取って必要台数を検討する。というようなアプローチが取りにくい時代でした。
仮想化
その後、仮想化技術が出てきました。すると、一括してサーバを購入し 必要に応じてそのインフラの上で仮想サーバを動かして利用する。という世代が来ます。
この世代では、サーバの調達期間は劇的に短縮され、アプリケーションのベンチマークを取って、必要なだけ仮想サーバを用意する。というようなアプローチがとりやすくなりました。
しかし、それはアプリケーションエンジニアの目線であり、この裏では結局ハードウェアをメンテナンスするインフラエンジニアがハードウェアの需要予測をしたり、調達したりをしていました。
また、アプリケーションエンジニアの要望に迅速に応えられるような体制にするには、余剰にサーバインフラをもつ必要があり、まだまだ課題があった時代といえます。
IaaS (Infrastructure as a Service)
その後、Amazon EC2 を代表とする IaaS が登場します。IaaS は Amazon のようなクラウドベンダーが一括してサーバを購入し、利用者に提供するサービスです。
これによって、ハードウェアの保守や需要予測が必要なくなり、またクラウドベンダーが膨大な量のハードウェアを調達するようになったことで、低コスト化がすすみました。
コンテナ
これまで。というには新しすぎる技術ですが、IaaSには無かったポータビリティを実現したのがコンテナです。
歴史自体は古いのですが、Docker の登場で一気に火がついた技術です。
Chef や Ansible などを利用してプロビジョニングの自動化をおこない、Vagrant のような技術を利用して、手元でなるべくサーバに近い仮想サーバを作って、環境に齟齬が発生しないようにしよう。というアプローチから一歩進めて、
コンテナの世代では コンテナのイメージを作成し、そのイメージをどこで動かすか。という差でしかなくなりました。
このように、過去を振り返ってみるとサーバ開発技術の変化は、エンジニアにとって開発しやすくなるための変化でした。 仮想化技術によって『環境構築の期間の短縮』を実現し、その後は Chef や Ansible のようなプロビジョニングツールや、コンテナ技術によって『アプリケーションのポータビリティ』が確立してきたことになります。
サーバ開発の未来
今、エンジニアの頭を悩ませているのは、『インフラ保守・管理』でしょう。 サーバの死活監視や、セキュリティインシデントへの対応、キャパシティの管理など、インフラにまつわる業務は多岐にわたります。 これらの悩みは『サーバレス』が解決してくれるものです。
次世代の PaaS (Managed Container?)
コンテナ技術に関しては、AWS の ECS や GCP の GKE のような、コンテナイメージを預けたらあとは起動するだけ。というところまで来ています。 しかし、死活監視・セキュリティインシデントの対応、キャパシティの管理など悩みは解決したとは言えない状態です。
今後、もうすこし時間が経ってくると コンテナイメージを登録するだけで、サーバへのエントリポイントが用意され あとは自動的に死活監視をしたり、スケールしたりしてくれる PaaS が出て来る（ECSやGKEが充実してくる）のではないかとおもいます。
FaaS
また、その先にある未来として、FaaS をベースとしたアプリケーション開発環境が整ってくると、アイドルタイムには費用が発生しない。 PaaS のオートスケールではスパイクのようなアクセスには対応できなかったところが対応できるようになる。というような変化が訪れるのではないかとおもいます。
FaaS が普及する上で難しいところとして、使い慣れたアプリケーションフレームワークで開発できない。という面があります。FaaS は関数の集合体としてアプリケーションを設計しなければならず、従来のモノリシックなアプリケーションフレームワークとは相性が悪いです。 また、FaaS は仕組みとして、関数の実行時にコンテナが起動し、実行が終わると破棄されることから、関数のスコープ外の変数を保持できないため、それを意識したキャッシュ戦略など、サーバレス特有の設計が求められます。
そういった側面もあり、FaaS がアーキテクチャとして魅力的だとしても、当面はコンテナベースのPaaS が先行して浸透するのではないかと考えています。 しかし、開発環境の整備が進むに連れ、将来的には FaaS ベースの設計によっていくことになるのではないかと予想します。
GS2 が変えるゲームサーバ開発の未来
Game Server Services(GS2) は世間に先駆けて全面的に FaaS を採用しました。
スケーラビリティ
その結果として、大量のアクセスを捌けるスケーラビリティを実現することが出来ました。 残念ながら、バックエンドでデータベースに利用している DynamoDB がキャパシティを予約しなければならない仕様のため、 FaaS の最大の魅力であるスパイクに強い特性を活かせていないのが現状です。 しかし、現状でもインスタンスタイプに対してリニアに性能が伸びるように設計されており、メニューにない性能が必要になったとしても提供が可能です。
将来的に、DynamoDB の代わりとして使えるスケーラブルなデータベースが利用できるようになったタイミングで、 インスタンスタイプのような仕組みはなくして、完全にAPIコール回数で課金するような形式に変更したいと考えています。
高可用性
次に、可用性です。 通常のWEBアプリケーションでは、サーバに常時プロセスが起動しています。 そのため、そのプロセスが起動しているサーバが不調になったり、あるいは基盤のハードウェアが故障したときにはプロセスが維持できなくなります。 そのような事態に備えて、サーバを冗長化したり、データセンターレベルの障害に備えて Multi AZ (Availability Zone) でサーバを配置する対応することになります。 FaaS の場合は 関数が実行されるサーバはオンデマンドで決定されます。そのため、ハードウェアの故障の影響は受けません。 また、特に意識しなくても勝手に Multi AZ で実行基盤が提供されており、データセンターレベルの障害の影響も受けません。
手軽に FaaS の魅力を提供
GS2 は FaaS に対応した新しいパラダイムの設計を頑張って乗りこなさなくても、FaaS の魅力を受けられるよう Functional SaaS としてサービスを提供できました。 GS2 のサービスはゲーム開発の分野でコモディティ化した機能をマイクロサービス化して提供していますので、SDKを使って手軽に組み込むことが出来ます。
マッチメイキングやランキングといったゲームに特化したサービスから、メッセージボックスや指定した時刻にURLにリクエストを出すcronのようなサービスなど、ゲーム以外の用途でも使えるサービスも提供しています。 サービスの名称からゲーム開発じゃないと関係ない。と思われがちですが、一般的なWEBサイトにも応用できるサービスになっていますので、ご興味があれば Game Server Services をごらんください。
まとめ
ハードウェアを自社で管理していた時代から、IaaS などを利用してハードウェアを持たなくなった。という変化を遂げてきたように これからは OS や プロセス を管理していた時代から、サーバレス技術を利用して、死活監視やキャパシティ制御をしなくなった。という変化が訪れると予想します。
その手法としては、コンテナ + PaaS や FaaS といった技術が見えてきており、 昨今のマイクロサービス化の流れで、コモディティ化したマイクロサービスは そもそも自社で開発せず、Functional SaaS を利用する。という流れもあるでしょう。 これからは、WEBサービスやアプリケーションのコアな魅力にリソースを割けるよう、このような技術を取り入れて効率化していくことが鍵になるのではないかと考えます。