長友氏の自己紹介
長友健人氏：それではAWSのソリューションアーキテクトの長友健人から、「負荷制限を使用して過負荷を回避する」という内容についてお話しします。よろしくお願いします。
まず簡単に自己紹介させてください。私は長友健人と申します。アマゾンウェブサービスジャパンにソリューションアーキテクトとして、2022年4月に新卒入社しました。好きなAWSサービスは「AWS CodeBuild」、「AWS IAM Identity Center」です。
関心領域は、大学時代より研究していた機械学習と音響信号処理をかけ合わせたようなものに興味があります。また趣味として、フットサルやボルダリングを終業後とか土日によくやっています。なので、ジムやフットサルコートで見かけたら、ぜひ声をかけてください。
本セッションで話すこと・話さないこと
では本日お話しする内容ですが、今回元にした記事は、Amazon Builders' Libraryの「負荷制限を使用して過負荷を回避する」という内容です。（スライドを示して）こちらの記事は、スライドQRLを読み込んでもらうか、「Amazon 負荷制限」で検索してもらうとWebページの一番上に出てくるので、今回のこの発表中、または発表後に手元で確認してもらえればと思います。
本日お話しするアジェンダです。Amazon Builders' Libraryの「負荷制限を使用して過負荷を回避する」の中の、負荷制限とはなにか、負荷制限の何を考慮すべきなのか、そして最後に、負荷制限の一例についてお話しします。
これからお話しすること・しないことですが、お話しすることは一般的な負荷制限の仕組みについてです。また、Amazonが長年、負荷制限と関わってきて考えてきたこと、そして工夫についてお話しします。一方、お話ししないこととしては、具体的な実装方法とか、細かいAWSサービスの話はしませんので、この点はご注意ください。
負荷制限を考える時に大事な「アムダールの法則」
それでは、負荷制限とは何かについてお話しします。まず、負荷制限を考えるにあたって大事な法則があります。それがアムダールの法則です。こちらは、理論的にシステムのスケールの限界を見積もることを可能とする法則となっています。
（スライドを示して）理論的というだけあって、アムダールの法則はこの数式で表されます。「この数式は何を言っているんだ」ということですが、速度の向上率は「E」ですね。速度の向上率というのは、あるシステムがどれぐらい速くなったか、何倍速くなったかを表しています。
この速度の向上率が「r」、（つまり）システム中で並列処理可能な割合と、「n」（という）プロセッサの数で決められるといっています。
このシステム中で、「並列処理可能な割合」が少しピンとこない方が多いと思うので解説します。例えば、ある処理をワーカーノードに分散させたい時。その前処理となる部分は、並列処理が不可能な場合が多いです。このように、システムの中でどこが並列可能でどこが並列不可能かを分けた時に、そのシステムの処理の中で並列処理可能な割合、（つまり）並列処理が何パーセント可能かを表しています。
そして、この数式をグラフにしたものが右の図になっています。例えば並列処理可能な割合が95パーセントのシステム。青の線を見てみると、プロセッサの数を10の5乗個のように非常に大きな数にしたとしても、速度の向上率は20倍程度にとどまってしまいます。
また、システムの並列処理可能な割合が90パーセントのオレンジの線を見てみると、プロセッサの数を10の5乗個にしたとしても、10倍程度にしかスピードが上がりません。そういったことを図のアムダールの法則がいっています。つまり、アムダールの法則は「並列化による処理速度向上には限界があるよ」といっているのです。
大量のリクエストを処理する際の3つのアプローチ
（スライドを示して）大量のリクエストを処理することによって過負荷が起きてしまう際のアプローチとして取られる手法を、このスライドでは3つ挙げています。
1つ目が、リソースのスケーリングという方法です。リソースのスケーリングとはサーバーの数を増やすような方針で、AWSが非常に得意としているところです。EC2の数を増やして、サーバーの台数を増やすみたいな方針です。こちらの方針は、先ほど説明したアムダールの法則に従って、性能の向上には制限があることがいえます。
もう1つのアプローチとして、リトライ／バックオフという方法があります。例えばWebサービスにアクセスした時に、「そのWebサイトが非常に遅くてずっとローディングしている状態なので、とりあえずリトライする」という経験はみなさんにもあると思います。
あと、サーバー間も通信し合って同じようなことをしています。例えばサーバーAからサーバーBにリクエストを送った時に、エラーが返ってきたとします。もう一度サーバーAからサーバーBにアクセスしてみて、成功することもあります。
ですが、エラーを1回返してすぐにリクエストすると、もう1回エラーが返ってくる確率が高いので、一定時間を空けてリクエストする。またエラーが返ってきたらさらに時間を長くしてリクエストするという、エクスポネンシャルバックオフといった方針も取られます。これらの方針は成功することもあるのですが、場合によっては負荷を増大させてしまって、サーバーがより悪い状態になってしまうことがあります。
これらのリクエストを成功させる方針、うまくいかなかった場合に考えられる1つの方針が負荷制限です。負荷制限とは、システムが処理する量を抑制して性能の一貫性を保つアプローチです。
負荷制限は「過負荷時にいくつかのリクエストを脱落させシステムを保護する」手法
その負荷制限とは、過負荷の際にリクエストのいくつかを脱落させて、システムを保護する手法です。（スライドを示して）こちらの図を見てもらうと、クライアントからのリクエストが矢印で表されているのですが、規定以上のリクエストを脱落させています。
今回は5本の矢印のうちの2つのリクエストを脱落させています。規定以上のリクエストは脱落させて、規定以内のリクエストに関してはアクセプトして、ちゃんとリクエストを返す。これによってシステム全体をダウンさせることなく、サービスの継続が可能となっています。アクセスの数が予想できないような、突発的なスパイクが発生するようなワークロードでも、予測可能な一貫したパフォーマンスを維持させることが可能となります。
そもそも過負荷とはどのような状態なのか
先ほどから言っている過負荷ですが、状態を少し丁寧に見てみます。（スライドを示して）このスライドに出てくる用語として、スループットとグッドプットというものがあります。スループットは単位時間あたりのリクエスト数で、グッドプットはスループットのうち、正しく処理されたリクエストの数だと思ってください。
一般的なサービスだと、スループットの増加にしたがってレスポンスタイムが増加していきます。そして、増加していくにあたって、ある点でクライアントタイムアウトに同じようなレスポンスタイムになってしまいます。
この時のグッドプットの状態を見てみると、最初はスループットが増加するにあたってちゃんとリクエストを返しているので、グッドプットが比例して上がっていきます。そして、ある点を境にクライアントタイムアウトが発生してしまうレスポンスタイムになってくるので、グッドプットの数が激減してしまいます。そして、最終的にはグッドプットが0個になって、システムが落ちてしまうような状態が過負荷と言えます。
こちらの過負荷を回避する方法の1つが負荷制限です。負荷制限によって、レスポンスタイムとグッドプットを保つことができます。どういうことか見てみると、例えば負荷制限を適用しない場合、スループットの数が増えていくと、クライアントタイムアウトに達するようなレスポンスタイムになっていました。それに対して負荷制限をかけることによって、クライアントタイムアウトに達しないようなレスポンスタイムで保つことができます。
グッドプットのほうを見てみると、スループットの増加にしたがって、グッドプットは比例して増えていきます。負荷制限をしなかった場合はグッドプットが激減していたのに対して、負荷制限を実施することで、グッドプットの数を一定に保つことができます。これによって、予測可能な一貫したパフォーマンスを維持することが負荷制限では可能になります。
（次回に続く）
