只今、クラウド基盤「Google App Engine(以下、GAE)」の連載しています。
今回も前回に続いて、「インスタンス時間」について理解を含めていきたいと思います。
おさらい
まずは今までのおさらいから。GAEは「従量課金制」ですので、消費するほどにお金が多く発生します。
①アクセスが増える。
↓
②インスタンスが立ち上がる。
↓
③インスタンス時間を消費する。
この３段ロジックです。
例えば、アクセス者が１人だった場合、インスタンスは１コしか立ち上がりません。
最初にリクエストが来て、この時にインスタンスが立ち上がると当時に、一定時間かけて処理を行います。
処理が終了した後、その瞬間にインスタンスが即死するわけではなくて、しばらくは「アイドル状態」で待機します。
以下みたいな状態のイメージです。
赤色の部分が処理中、白色の部分がアイドル中のイメージです。
アクセス数が少ないと「インスタンスはアイドル状態で立ち上がっている」という状況になりますので、アイドル時間中はインスタンスを無駄遣いしていることになりますね。
出来ればこの無駄は省きたい所ですが「アイドル状態で待ち構えているから、リクエストが来た時に高速に反応できる」という側面もあるのです。多少の無駄遣いは仕方がありません。
インスタンスが死んでいる時にアクセスが来ると、「スピンアップ」という重いインスタンス起動処理が走ります。アイドル状態からの起動と、死んでいる状態からの起動ではスピードが全然違います。
（「スピンアップ問題」はGAEの数ある制限の中でも頭を悩ませる超重要問題なのですが、それについては今後に記事にしたいと思います。）
とにかく、アクセスが同時に１人だった場合は、こんなイメージです。
次に、これが２人になると、以下のようになります。
ご覧のように、少し待って「１インスタンスで２人捌く」という結果になります。
「１人なら１インスタンス。２人なら２インスタンス。１００人なら１００インスタンスだ！！」
なんて効率の悪いことにはなりません。
少ない人数でしたら１インスタンスで捌いてくれます。
ただし、待ちが発生しますけどね。
同時にアクセスが来たら、片方にはもう一方の処理が終わるまで待って貰います。
その待ち時間を「Pending Latency」と言います。
- 待ち時間が短いうちは１インスタンスで捌く。
- 「待ち時間長過ぎ！！ 遅えぇぇぇぇぇッ！！」となったら新規インスタンス起動
こういう関係なのですよ。
スーパーのレジに人が溜まってきたら、新しい人が別のレジに入って捌くのと似たようなものです。
アクセス殺到時のイメージが以下の図です。
最初のうちは１インスタンスで頑張ってくれていますが、アクセスが殺到したら、アクセス者を待たせないようにもう１コインスタンスを起動して、そっちにもアクセスを振り分けるという意味です。
まとめますと、
- １リクエストの処理速度
- リクエスト数
GAEのインスタンス時間は、この２つの要素の直撃を受けます。
リクエスト数を減らすことは出来ませんので、「１リクエストの処理速度」を出来る限り高速化すること。
この辺りがGAEのコツです。
「動けば良い」などというゴミロジックは、GAEでは厳禁！！
インスタンス消費時間という形で、明白にお金という形で報復を受けます。
高速ロジックこそがGAEの正義です。
ロジックを組むプログラマーの腕前が会社の経営を左右するかもしれないのです。
塩梅をつける
と言っても、実は「設定」でこのインスタンス消費時間を下げることも可能なのです。上記に「アイドル状態」「待ち時間」という二つのキーワードが登場していますが、これらを手動で塩梅をつけることでインスタンス消費時間を下げることが出来ます。
アイドルインスタンス調整
アイドルインスタンスとは「次のアクセスに備えて待機しているインスタンス」のことです。アイドル状態で多数のインスタンスを控えさせておけば、急にアクセスが来た時でもすぐに対処出来ます。と言っても、アクセスが来ていない場合は単なる穀潰しです。
「多少時間がかかっても、アクセスが来てから新規インスタンスを立ち上げれば十分」というの論理がＯＫであれば、「最大アイドルインスタンス数を下げる」という設定を行うことで、穀潰しを抹殺することが出来ます。
但し、その分だけ「スピンアップ」というインスタンス起動処理の発生頻度が多くなりますのでご注意を。
待ち時間調整
上記には「アクセス者の待ち時間が長くなったらインスタンス起動」とありますが、「それって具体的にどれくらい待ち時間が長引いたらインスタンスが起動するの？」という話です。0.1秒待っただけで新規インスタンスを起動するようでは、そりゃインスタンスは些細なことでポンポン立ち上がってコストを大量消費してしまいます。
「５秒や１０秒くらい大人しく待ってろ」というの論理がＯＫであれば、「許容待ち時間を長くする」という設定を行うことで、過剰なインスタンス起動を回避することが出来ます。
これらの設定を行う個所が、アドミンコンソールの「Application Settings」です。
ここに「Max Idle Instances(最大アイドルインスタンス数)」と「Min Pending Latency(最少待ち時間)」がありますね。
デフォルトではこれは「Auto」になっていますが、「Auto」というのは「最高パフォーマンス設定」のことで、この状態が一番速い代わりに高価です。Autoは本当に高速で、0.1秒待っただけでも次が上がってしまうような超高速モードらしいです。
これを最低設定の「Max Idle Instances：1」「Min Pending Latency：15s」まで手動で下げてしまえば、パフォーマンスが低下する代わりにインスタンスの起動が抑制され、結果コストが安く出来るのです。
「待ち時間１５秒とか遅過ぎだろ！！ でも３秒くらいなら許せるかな」みたいに、そのサービスの保証水準を鑑みて、各自調整するのが良いでしょう。
終わりに
以上が、インスタンス時間に関連する基礎知識でした。しかし、これはあくまで「理論上の話」です。
次回は、いっちょ、自前でDoS攻撃を仕掛けて負荷テストを決行してみたいと思います。
一体、どれくらいのアクセスを捌くことが出来るのでしょうね。。。
0 件のコメント:
コメントを投稿