GAEのスケーリング 前編 <仕組みについて>

  • このエントリーをはてなブックマークに追加

ご注意

この記事は 2015年1月16日 に書かれたものです。内容が古い可能性がありますのでご注意ください。

今回は、こちらの公式ドキュメントをもとに、GAEのスケーリングの仕組みと最適化のやり方について紹介します。記事は前後編の2段構成でお送りします。

前編 GAEのスケーリングの仕組みについて
後編 スケーリングの最適化の実践

はじめに

まずは皆様に、今回参考にしたこちらのドキュメントの主旨とGAEのスケーリング技術の何がすごいのかを知ってもらうため、ドキュメントの序文を抜粋してみました。

数百万人から同時にアクセスされても耐えられるサイトを作れと言われたら、あなたはどうしますか?果敢にも高速で信頼性の高いサービスを作ろうとするかもしれませんが、そのようなサイトを作る時に最も重要となるのは、リクエスト数に応じて適切にスケールすることでしょう。

あなたのチームには、スケーラブルで信頼できるWEBサーバを構築した実績がありますか?そのようなサーバを開発・運用・保守するために掛かるコストを、正しく見積もることができますか?そのような仕事ができる優秀な人材を雇うノウハウはありますか?

GAEを使えば、このような難題を簡単に解決できます。このドキュメントでは、GAEが、どのようにユーザリクエストを処理し、アクセス数の変動に応じたスケーリングを実現しているのかについて記載しています。さらに、対費用効果を最適にするために開発者がどのような設定をすればよいかについても説明しているため、この記事を読めば、あなたはGAEの効力と柔軟性を十分に引き出すことができるようになるでしょう。

少し扇動的な文章ですが、実際にGAEを使っている立場としても確かに素晴らしい技術だと思っています。

それでは、Googleが豪語するApp Engineの素晴らしいスケーリングの仕組みについて説明していきたいと思います。

App Engineのスケーリングの仕組み

App Engineでは、どのようにスケーリングを実現しているのでしょうか?その仕組みを、以下2つの特徴をもって説明したいと思います。

  • ユーザからのリクエストを受けて辿る処理フロー
  • コンテナ技術を使ったインスタンスのスケーリング

ユーザからのリクエストを受けて辿る処理フロー

image05

図1.ユーザのリクエストが辿るフロー

図1にユーザのリクエストがアプリケーションへ到達するまでのフローを示します。ユーザのリクエストは、まず、地理的に最も近いGoogleのデータセンターへ送られます。そこでは、Google front endがリクエストを受け、Google独自のfiber backboneを通して、App Engineデータセンターへリクエストを送ります。(Edge Cacheについては、この記事では触れませんが、ご了承下さい。)

App Engineデータセンターは、以下の構成によって成り立っています。

App Engine front end

App Engineアプリケーションのロードバランシングとフェイルオーバーの役割を担います。また、ユーザリクエストを、App serverかStaticServerへディスパッチします。

App server

実際のアプリケーションが動作する部分です。この部分のApp Engineアプリケーションのインスタンス(以下、インスタンス)が作成・削除されることにより、スケーリングを実現しています。また、各インスタンスの環境にはApp Engineが提供するサービスのAPIやライブラリがあり、開発者は簡単に優れたアプリケーションを作ることができます。

Static server

App Engineアプリケーション内の静的ファイルを提供することに専念するサーバです。

App master

全体の指揮者として働きます。デプロイ時、App serverにはソースコードを、Static serverには静的ファイルをアップロードしています。

上記の構成のうち、App Engine front endとApp serverが稼働中のインスタンスをトラッキングしており、ユーザリクエスト数の変動に応じてインスタンス数が変動します。

コンテナ技術を使ったインスタンスのスケーリング

App Engineでは、コンテナベースのPaaSを採用しており、ひとつのインスタンスをひとつのコンテナとして扱っています。
image03

図2.VMとApp Engineの比較

この仕組みのメリットを理解していただくために、図2を参照下さい。この図は、VMを提供するハイパーバイザ型のIaaSを使ってインスタンスのスケーリングを実現した場合と、実際のApp Engineを比較したものです。

両者の最も大きな違いは、OSにかかるオーバーヘッドです。App Engineには、このオーバーヘッドが無いことため、以下の恩恵を得ることができます。

  • インスタンス起動にかかる時間が短い
  • OSのイメージを準備・保持・管理するコストがない
  • ホストPCにかかるCPU・メモリなどのリソース負荷が小さい

前編をまとめてみて

まだ知名度が高いとは言えませんが、App Engineは最先端のスケーリング技術を使った、可能性を秘めたサービスなのではと思います。また、App Engineの高い性能というのは、スケーリングさせるリソースを極力減らすことで実現しているように思いました。静的ファイルはインスタンス間で共有する、コンテナ技術を使うことでVMのようなOS部分のオーバヘッドを減らす、といった点です。
次回は、GAEの効力と柔軟性を引き出すための、スケーリングの最適化の方法について説明します。

※記事に利用している図はこちらのドキュメントから引用しております

前編 GAEのスケーリングの仕組みについて
後編 スケーリングの最適化の実践
  • このエントリーをはてなブックマークに追加

Google のクラウドサービスについてもっと詳しく知りたい、直接話が聞いてみたいという方のために、クラウドエースでは無料相談会を実施しております。お申し込みは下記ボタンより承っておりますので、この機会にぜひ弊社をご利用いただければと思います。

無料相談会のお申込みはこちら