2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
長友健人氏:では、負荷制限を導入した時にどのようなことに考慮すればいいのかをお話しします。負荷制限の実装で考慮すべき事項は今回の発表の元となった記事にたくさん書かれているんですが、今回はそのうち5つをピックアップして紹介します。
1つ目は、「リクエストに優先順位をつけましょう」という内容です。「優先度の高くないリクエストはオフピーク時に処理しましょう」といっています。例えば、クライアントからのアクセスが大量にサーバーに来ていて、サーバーが過負荷な状態になっているとします。このタイミングで緊急度の高くないクローラーだったり、バッチからのリクエストを処理してしまうと、サーバーがさらなる過負荷に陥ってしまいます。
なので、ピーク時を避け、クライアントからのリクエストが少ない時にクローラーやバッチといった緊急度の高くない処理を回すことで、負荷を軽減できます。
ここで注意しなければいけないのが、ヘルスチェックのためのロードバランサーからのピンなどです。システムを維持するために大事なリクエストは優先度が高いです。サーバーに対して行われるリクエストを洗い出して、どれが優先度が高いのか、低いのかをあらかじめ決めておく必要があります。
次に、無駄な処理コストを使わないという内容です。これは一般的に言われていることですが、過負荷時にレスポンスの遅さから、ユーザーは頻繁にリトライするといわれています。Webサービスが遅い時にはとりあえずリトライして試してみるということですね。このリトライがサーバーにとっては良くない事態を引き起こします。
例えば、クライアントがリクエストして1つ目のリクエストの時に、レスポンスが来ないのでリトライするとします。で、2回目のリクエストを投げます。そして、サーバーが1個目のリクエストを処理します。
しかし、ここでクライアントは2回目のリクエストをしているので、1回目のリクエストに関しては、すでにListenしていないことになります。なので、サーバーは無駄な処理をしてしまったことになります。こういった事態を避けるために、優先度が低いと分類されるリクエストを削除するなどの対応が必要となります。
次に、クロックの扱いに気をつけるという内容です。こちらも無駄な処理を防ぐという観点です。「クライアントタイムアウトに達してしまうぐらいサーバーの処理時間がかかってしまったら、途中で処理を中断してくださいよ」という内容です。
この実装を実現するために、クライアントはリクエストにタイムアウトの絶対時間を持たせる必要があります。また注意事項として、クロックをサーバー間で同期させることが重要です。
ここで、サーバー間のクロックが同期していない例を考えてみます。まず、クライアントが2秒後、23時55分12秒にタイムアウトしますという情報をリクエストに持たせて、Server1にリクエストを行います。ここでクライアントとServer1は同じクロックを持っています。そうすると、Server1はタイムアウトまであと2秒あることになります。正しくタイムアウトまでの時間を見積もって、Server1の処理を行うことができます。
次に、Server1からServer2にそのリクエストを投げるような処理があったとします。ここでServer1とServer2のクロックが同期されていなかった場合、Server2が正しいタイムアウトの時間を見積もれません。Server2が処理時間の長いものを処理した場合、クライアントがすでにタイムアウトしてしまっていて、無駄な処理をしてしまったという事態になり得ます。こういった事態を避けるために、クロックをサーバー間で同期させることが重要といえます。
次に、「キューの扱いに注意しましょう」というお話です。過負荷の状態になるとサーバーがリクエストをすぐにさばくことができないので、いったんキューにためておくことがよくあると思います。
リクエストの数が増えていくと、キューされるものも多くなって、キューされる時間がどんどん長くなっていってしまいます。(スライドを示して)このスライドの図の例で、リクエスト1、リクエスト2、R1、R2、R3が、20分、15分、10分と非常に長い時間にわたってキューされているとします。
そうすると、クライアントはもうListenしていないので、レスポンスを返したとしても成功確率は非常に低いです。なので、キューに置かれる上限時間を定めてあげて、古すぎるものは削除するという処理を入れます。
そうすると、新しく入ってきた成功確率の高いリクエスト、このR4を優先してサーバーが処理できます。これによって無駄な処理をせず、成功率の高いリクエストだけを処理してクライアントに返すことができます。
もう1個記事の中で言われているのは、例えば、Webアプリケーションフレームワークを使った時に、内部の実装まで深く意識していないと、デフォルトでどこかでキューしていたりキャッシュをしているような状態があります。そうなると正しい時間が見積もれないから注意しなさいといったことも書かれています。
次に、レイヤーごとに保護するという内容です。「各レイヤーで負荷制限を実施して、サービスの状況を監視しましょう」といったことをいっています。(スライドを示して)こちらのスライドではAWSサービスのアイコンをいくつか置いていますが、これはAWSサービスで実現される一般的なサービスの実装の例です。
まず左から、AWS WAFは、Web アプリケーションファイアウォールのサービスです。そしてAmazon CloudFrontというのは、CDNのサービスです。そしてElastic Load Balancingというのはロードバランサーのサービスで、Amazon EC2はここではサーバーとして使っています。そして最後にAmazon RDSというデータベースのサービスになっています。
AWS WAFだと、リクエストのレート制限を設定できます。例えば、「5分間に、このIPからは何件のリクエストまで許可しますよ」という設定ができます。
Amazon CloudFrontでは、ディストリビューションあたりの単位時間のリクエスト数が制限されています。またAmazon RDSでは、MAXコネクションで最大接続数が管理されています。このように、各レイヤーで負荷制限を実施できます。
各レイヤーで負荷制限することで、どこで何が起きて負荷制限したのかをあとで追うことができます。つまり、前段となるサービスで後段のサービスのリソースを守ることができるメリットがあります。
最後に、負荷制限の一例についてお話しします。今回は、両備システムズさまの新型コロナワクチン接種予約システムについてです。こちらの例は、予約困難なアクセス数をバーチャル待合室機能で対応した例になります。
バーチャル待合室機能というのは、例えば、予約システムにアクセスした時にシステムが過負荷の場合、待合室のページにリダイレクトされます。待合室のページでは、「あと何分待ってください」ということであったり、「あなたは何人目です」というような表示がされていて、順番が来たら予約システムに入れるようになっている実装になっています。
この例の開発要件の課題についてです。当時、ワクチンが日本にどれぐらい入ってくるかわからない状況だったので、アクセス数がワクチンの流通量に反映されるこのシステムは、アクセス数の予想が非常に困難でした。そして、アクセスの減少に従ってコストの面で規模を縮小させることができる柔軟性のあるアーキテクチャが必要でした。
これを実現させるためのアーキテクチャのポイントについては、負荷状況をCloudWatchでモニタリングして、Auto Scalingでシステムを柔軟に変更させたり、CloudFront Functionsで先着方式と抽選方式の混合方式によるバーチャル待合室機能を作成したりして、最大5分間で1,000万リクエストのアクセスでも動作する実績を残すこととなりました。
この例は、バーチャル待合室機能という負荷制限の仕組みによって、予測不可能であったワークロードを予測可能なワークロードに落とし込んだ例となっています。
まとめとなります。負荷制限とは、リクエストのいくつかを脱落させてシステムを保護する手法です。システム全体を落とさずにサービスの継続を可能としていて、予測可能な一貫したパフォーマンスを維持します。負荷制限の実装には考慮すべきことがたくさんあります。
(スライドを示して)こちらに関しては、本発表と元の記事を参照してもらえればと思います。
これで私の発表は以上となります。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには