アーカイブ動画

キャッシュのメリットとリスク、あるべき戦略とは

アマゾンウェブサービスジャパン合同会社
技術統括本部　ソリューションアーキテクト　川島 拓海氏

最初に登壇した川島氏を含め、今回の登壇者5人はいずれも2022年に新卒でAWSに入社して、SAとして活躍している。川島氏のセッションでは、『Amazon Builders' Library』の「キャッシングの課題と戦略」をもとに、一般的なキャッシュの運用やAmazonが考えるキャッシュの検討すべき事項について、わかりやすく解説している。

キャッシュとは、ネットワークを経由したデータベースなどの呼び出しにおいて、呼び出しのレイテンシー、呼び出し量が増えたときのスケールアウト費用の問題を解決するものだ。ここでは、キャッシュの後ろ側にある、キャッシュミスの際にデータを取りに行く元のリソースをダウンストリームリソースと呼ぶこととする。

最初に紹介したのは、ローカルキャッシュと外部キャッシュの分類だ。ローカルキャッシュとは、既存のダウンストリームリソースの内部に実装するキャッシュ。一方の外部キャッシュは、ダウンストリームの外部に実装するキャッシュである。ローカルキャッシュと外部キャッシュには、次の図のようにそれぞれ特徴と問題がある。

ローカルキャッシュの問題は、第一にサーバー間のキャッシュで一貫性が保証されないこと。第二に新しいサーバーが立ち上がるときに「コールドスタート」問題が起こること。第三にサーバーの負荷がサーバー群のサイズに比例することだ。

第一と第二の問題は緩和が可能だが、第三の問題の緩和は難しい。このローカルキャッシュが抱える問題を、緩和・解決できるのが外部キャッシュである。しかし、もちろん外部キャッシュにも問題はある。新しいサービスが追加されるとモニタリング・管理・スケーリングなどを別枠で考える必要があるため、運用コストが増加することだ。

一方、外部キャッシュにも運用コストが増加するといった特有の問題が存在する。ここで、Amazonのキャッシュの運用に関するベストプラクティスとして、以下の3点が挙げられた。

• 他のサービスと同様に厳密に管理、モニタリングする
• キャッシュが使用できない場合にサービスが回復力を持つようにする
• 他のサービスのバージョニングと対応できるようにする

第二に考慮すべきは、キャッシュポイズニング攻撃だ。これを防ぐには、攻撃者がキャッシュのダウンストリームとの通信に介入できないように、ダウンストリームプロトコルの脆弱性をなくすことが重要となる。

第三がサイドチャネルタイミング攻撃だ。キャッシュ内のデータの有無をもとに、他のユーザーのリクエスト履歴やキャッシュデータの保持ルールを推測できるというもの。これを防ぐ場合は、内部の計算時間と外部への応答時間と対応をずらし、計算時間が推測できないようにする必要がある。

また、セキュリティ以外にも、キャッシュサイズ、有効期限ポリシー（TTL）、削除ポリシーを慎重にテスト・検証・調整することも考慮する必要がある。他にも、ソフト TTL とハード TTL の併用、ネガティブキャッシュの利用といった対応策も挙げられる。

ダウンストリームエラーの際に、キャッシュが適切に対応できるようにすることも重要だ。そこで取り上げられたのが「Thundering Herd」。ダウンストリームリソースへのリクエストが同時に多発し、リソースが使用できない状態に陥ってしまう現象である。

対策としては、複数のリクエストをまとめて送信すること。キャッシュへのリクエストの増加にダウンストリームリソースが影響を受けなくなる。

キャッシュは非常に大きな恩恵をもたらすが、コスト・レイテンシー・可用性の観点からキャッシュの必要性を確認することも重要となる。川島氏は「キャッシュを用いるメリットが生まれるか、適切に判断した上で導入することが大事」と語り、セッションをまとめた。

※元記事：Amazon Builders' Library「キャッシングの課題と戦略」

負荷制限を使用して、過負荷を回避するベストプラクティス

アマゾンウェブサービスジャパン合同会社
技術統括本部　ソリューションアーキテクト　長友 健人氏

長友氏のセッションテーマは「負荷制限を使用して過負荷を回避する」。Amazonが負荷制限に対する取り組みの中で得た知見をまとめたものである。負荷制限とは、予測困難なワークロードを予測可能なものに落とし込む手法の一つである。

大量のリクエストが発生してシステムが過負荷の状態に陥った際、システムの応答成功率を上げるための手法の一つは、サーバーなどのリソースを増やす手法だ。リソースを増やしたとしても性能の向上には限界がある。 リトライ／バックオフもシステム応答の成功率を上げるための1つの手段として、よく用いられる手法だ。だが再試行を繰り返すこの手法は、場合によっては負荷を増大させてしまうことになる。これらの方法でうまくいかなかった場合に考えられる一つの方法が負荷制限である。

負荷制限とは、システムが処理する量を制御して性能の一貫性を保つアプローチ。過負荷の際にリクエストのいくつかを脱落させ、システムを保護する。一部のリクエストは失敗してしまうがシステム全体はダウンさせずにサービス継続を可能とする。

アクセス数が予想できない突発的なリクエストが発生するようなワークロードでも、予測可能な一貫したパフォーマンスを維持させることが可能となるのだ。

過負荷の状態をグラフで表したものが、以下の図である。スループット（Throughput）は単位時間当たりのリクエスト数、グッドプット（Goodput）はスループットの内正しく処理されたリクエスト数を表す。

過負荷の状態では、スループットの増加に伴い、レスポンスタイムが増加してタイムアウトが発生してしまう。図を見ればわかるように、ある点を境に正常なレスポンスが激減する。 だが、負荷制限をすることによって過負荷を回避し、レスポンスタイムとグッドプットを保つことができるというわけだ。

負荷制限の実装で考慮すべき事項については、元記事から5つ取り上げて紹介された。

1つ目は、リクエストに優先順位を付けること。過負荷時に優先度の低いリクエストを処理すると、さらなる過負荷を招く。

この事態を避けるために、例えばシステムの継続に必要なヘルスチェックのためのpingは優先度が高いので先に処理し、バッチ処理のような優先度の低いリクエストはオフピーク時に処理する。

2つ目は、無駄な処理コストを使わないこと。過負荷時にはレスポンスの遅さから、ユーザーは頻繁にリトライすることがある。前のリクエストはユーザーから無視され、サーバーの処理が無駄になるため、優先度の低い古いリクエストは削除する対応が必要になる。

3つ目は、クロックの扱いに気をつけること。無駄な処理を防ぐため、クライアントタイムアウトに応じて、サーバーは途中で処理を中断する。この実装を実現するために、クライアントはリクエストにタイムアウトの絶対時間を持たせること、そしてクロックをサーバー間で同期させることが重要になる。

4つ目は、キューの扱いに注意すること。過負荷状態になるとリクエストがキューされる時間が長くなり、クライアントがタイムアウトしてしまう可能性がある。すでにクライアントがタイムアウトしているリクエストを処理しても無駄な処理となってしまう。

そこで上限時間を定めて古いものは削除し、新しいリクエストを優先して処理することで、システム応答の成功率は向上する。

5つ目は、レイヤーごとに保護すること。各レイヤーで負荷制限を実施し、サービスの状況を監視するのである。次の図はAWSサービスで構成されるシステムでレイヤーごとに負荷制限を実施している例である。

負荷制限を実装するにあたって考慮すべき事項はたくさんある。長友氏は「今回紹介しきれなかった知見も元記事では紹介されているので、ぜひ参考にしてほしい」とメッセージを送り、セッションをまとめた。

※元記事：Amazon Builders' Library「負荷制限を使用して過負荷を回避する」

Amazonにおけるダッシュボードのベストプラクティス

アマゾンウェブサービスジャパン合同会社
技術統括本部　ソリューションアーキテクト　吉澤 巧氏

3番目に登壇したのは、技術統括本部　ソリューションアーキテクトの吉澤巧氏。セッションテーマは「Amazonにおけるダッシュボードのベストプラクティス」だ。

吉澤氏は学生時代に気象予報士を取得、民間の気象会社で予報業務に従事した経験を持つ。そのときに気づいたのは、ユーザー目線の情報を提供することだという。

「天気予報で気温が18度と言われても、ユーザーは着るべき服装を想像しにくいものです。本当にユーザーが求めるのは、どんな服を着たら良いのかという情報です。ITシステムも同じくユーザー目線の情報というものが大切で、本題のダッシュボードにおいても利用者を想定して作成していくべきです。」（吉澤氏）

Amazonではサービス設計、コーディング、構築、テスト、デプロイ、スケーリングと同じレベルで、ダッシュボードが大切だと考えている。その理由は、どこで何が起こっているのか、システムの動作をリアルタイムに把握するためである。

Amazonにおけるダッシュボード活用のポイントは大きく2つある。

第一は、アラートの作成だ。常にダッシュボードを監視することは実質不可能。だからこそ最も大事なメトリクスを評価するアラートを作成するのである。アラートが鳴った際は、必要なダッシュボードを使って、迅速に現状を確認する。

第二に、役割、用途に応じた複数枚のダッシュボードを用意しておくことである。障害時を例にあげると、運用メンバーには原因を特定するためのダッシュボードを、ビジネス関係者には影響範囲をモニタリングするためのダッシュボードを用意する。

ダッシュボードは、誰がどのような用途で利用するのか。言うなれば顧客指向に基づいて設計されていく。そのようにして作成されるダッシュボードは、比較的抽象度の高い高レベルなもの、バックエンドマイクロサービス等、より機能にフォーカスした低レベルなものの2つに分類される。

ダッシュボードの設計における、Amazonのベストプラクティスは複数あるが、今回は以下の5つを取り上げた。取り上げられなかったベストプラクティスについては、元記事を参照いただきたい。

1. 最重要なデータを一番上に配置する
   ユーザーは最初に表示されたものを大切と判断する傾向があるためである。
2. グラフのレイアウトは、想定できる最小のディスプレイサイズに合わせる
   つまり、横スクロールが不要なレイアウトを目指す。
3. アラートを設定する場合は、グラフにしきい値を表示する
   静的なしきい値を設定できない場合は機械学習（ML）を使うこともあるが、その場合でも正常範囲を描画する。
4. 各メトリクスもしくはウィジェットの真の意味をユーザーが理解していることを前提にしない
   グラフの横や下にメトリクスの説明を追加することで、誰がダッシュボードを見ても同じ解釈ができるようにする。
5. システムの特性に応じて状況に応じた複数のウィジェットを用意する
   例えばリクエストサイズ毎のレイテンシなど、場合わけしてウィジェットを用意する。これにより、障害時の原因の切り出しが容易になる。

ダッシュボードは一度作成すれば終わりではない。サービスの開発に合わせてアップデートをしないと、ダッシュボードは時代遅れになってしまう。そのためにAmazonでは、開発者が自分自身でダッシュボードをアップデートするための、2つのプロセスが存在する。

1つが、新しい機能をデプロイする前に、「ダッシュボードに何か変更はありますか？」と質問を挟み、開発プロセス中にダッシュボードを更新する。この時、ステージング環境にも同様のダッシュボードを用意すること、ダッシュボードのレイアウト管理にIaCを採用することがポイントとなる。

もう1つはデブリーフ。つまり障害が発生したあとの振り返りにおいて、ダッシュボードのアップデートを行う。デブリーフについては、「Amazon’s approach to failing successfully」の動画も確認してほしい。

ダッシュボードの観点では、「ダッシュボードはお客さまへの影響を明確にしたか」「障害原因を明確にすることに貢献したか」「修復時間を短くすることの助けになったか」という3つの質問を投げかけることがポイントだ。ここで1つでもNoとなれば、ダッシュボードを改善するアクションを検討するべきである。

このようにAmazonでは、ダッシュボードを常に改善していくプロセスが備わっている。

※元記事：Amazon Builders' Library「運用を可視化するためのダッシュボードの構築」

分散システムの課題とリーダー選挙

アマゾンウェブサービスジャパン合同会社
技術統括本部　ソリューションアーキテクト　松田 丈氏

続いて登壇した松田氏のセッションテーマは、「分散システムの課題とリーダー選挙」。 Amazon Builders' Libraryの元記事「分散システムの課題」「分散システムのリーダー選挙」を参考にしている。

分散システムとは、多数のコンピュータがネットワークで繋がり、連携して一つの作業を行うシステムのこと。分散システムは、オフライン分散システムとオンライン分散システムの2つに分けられる。両者の概要とメリットは図の通りだ。

さらにオフライン分散システムは、ソフトリアルタイムとハードリアルタイムの2種類に分かれる。明確な定義はないが、多少の遅延が許されるものがソフトリアルタイム、リクエスト／レスポンスがあり、遅延がほぼ許されないものがハードリアルタイムと考えるといいだろう。

今回のセッションの分散システムは、ハードリアルタイムのことを指す。例えば、次の図のような「2つのノード間での通信を行うケース」があったとする。

どんな課題が考えられるのか。まずはリクエスト（またはレスポンス）メッセージが消失しても、ネットワークの障害の可能性も、対向ノードの障害の可能性もあるが、それを各ノードが知る術がないことである。

次に送信ノード側では、タイムアウトとして処理の終了のハンドリングを行う必要があり、タイムアウトの時間を適切に設定することも課題となる。そして、受信ノード側のステート更新処理はべき等性を担保する必要があること。これはリクエストがリトライされる可能性があるからだ。

こういった過酷な状況下でも、データの一貫性を担保するにはどのような工夫が必要なのか。分散システムにおけるレプリケーションについて、松田氏が示したのが飛行機の予約システムの例だ。

単純な非同期レプリケーションを採用すると、レプリケーションの通信が不達になるなど、遅延の可能性がある。そうなってしまった場合、データの一貫性が保てないのだ。予約システムの例では、複数のユーザーが同じ座席を予約することに繋がってしまう。

とはいえ、同期レプリケーションを行うとすべてのノードの応答を待つ必要があり、逆に耐障害性が下がってしまう。この問題を解決するのが、リーダーノードという考え方である。

「先述の飛行機の予約システムのケースでは、書き込みをリーダーノードのみに許可することで、座席のダブルブッキングを防ぐことができるようになります。また全体の性能を向上させることもできる。これがリードレプリカと呼ばれる考え方です」（松田氏）

リーダーの決め方としては、信頼できるノードを固定してリーダーにする、分散合意アルゴリズムを用いる、ソフトウェアを用いる、リースを実装するなどの方法がある。

リースとはリーダーである権利を期限付きで取得する手法である。メリットとして、リーダーが障害を起こしても他ノードがリーダーに成り代わるため耐障害性を提供できることと、実装が比較的単純で理解しやすいことが挙げられる。

リース実装の課題は、時間計測に関する保証がないため、期限が切れているのにリーダーとして振る舞う場合があることだ。最も有効な対処法は、リースベースのロッククライアントを用いること。記事ではDynamoDB Lock Client、Apache ZooKeeperを挙げている。

リーダーが故障した場合は、再選挙が行われ、リーダーが引き継がれることになる。その引き継ぎには2つの工夫が必要となる。1つは処理すべき等性を担保すること。もう1つがデータの書き込みより先に他のノードへの伝達を行うことだ。

分散システムを理解することは、アプリケーション構築や運用にも活かせる。興味を持った人は元記事も読んでみよう。

※元記事：Amazon Builders' Library「分散システムの課題」「分散システムのリーダー選挙」

高可用性を実現する静的安定性という考え方

アマゾンウェブサービスジャパン合同会社
技術統括本部　ソリューションアーキテクト　堀 貴裕氏

最後に登壇した堀氏のセッションテーマの元記事は、「アベイラビリティーゾーンを使用した静的安定性」。静的安定性の定義は、障害によって依存関係が損なわれても、システムが動作し続ける性質であること。

一般的にシステムが高い可用性を持つためには、依存するシステムの可用性も高くする必要がある。だが「高パフォーマンスで高機能なAWSサービスを作る上で、すべての依存先の可用性を保つことは困難」と堀氏は語る。

静的安定性がないと、依存関係のあるシステムに障害が起きた際に、システム全体の動作が止まってしまう。そこで依存関係が損なわれても動作する静的安定性が必要になるのだ。

静的安定性を実現するシステムの例として、紹介されたのが以下図のECサイト。このECサイトでは商品購入サービスにも住所データのキャッシュを持たせている。こうすることで、住所変更サービスに障害が起こっても購入を継続できるようにしているのだ。

 AWSではデータプレーンとコントロールプレーンを分離することで、静的安定性を実現している。データプレーンとはサービスの基本機能。単純な依存関係しか持っておらず、高い可用性が求められる。

一方のコントロールプレーンとは、システムの変更機能（追加、変更、削除）を提供する。複雑な依存関係があり、可用性はデータプレーンほど要求されない。これらが完全に分離されることによって、コントロールプレーンに何か障害が起きても、データプレーンは動き続けるという設計がなされている。

具体的には、Amazon EC2という仮想サーバーサービスは、データプレーンにはネットワークやサーバー、ストレージなど絶対に止まることは許されない機能を提供し、コントロールプレーンではインスタンス作成や設定変更などの機能を提供する。

続いて堀氏は、アベイラビリティゾーン（AZ）を使用した静的安定性について説明を行った。AWSでは各AZを落雷、竜巻、地震などの潜在的な問題からの相関的な影響から保護するために、意味のある距離で物理的に分離している。それらを高速で暗号化されたプライベート光ファイバーネットワークで相互に接続しているのである。

AZを複数使用した高い可用性を持つアーキテクチャをどうやって実現すればよいのか。 一例として、下図のアーキテクチャがあったとする。これは堀氏が言うように「かなり典型的なアーキテクチャ」である。

仮に片方のAZに障害が起こったとする。するとEC2の能力が不足するため、オートスケーリングでインスタンスをAZに作成することになる。

インスタンス作成はコントロールプレーンの機能。つまりこのアーキテクチャは、AZ障害時に可用性の低いコントロールプレーンに依存していることになる。このようなコントロールプレーンに依存したアーキテクチャは静的安定性が低い。

静的安定性が高いアーキテクチャにするには、EC2のインスタンスを200％余分に用意し、オートスケーリングの設定は負荷テスト時の50％にするのである。だがもちろんデメリットはある。このアーキテクチャは問題を解決するが問題も存在する。それはコストが増大することだ。

この問題を緩和するアーキテクチャが、3つのAZを使ってインスタンスを150％余分に用意し、オートスケーリングの設定を負荷テスト時の66.6％にするという設計である。こうすることでAZ障害の際にインスタンス作成の必要がない静的安定なアーキテクチャを維持しつつ、先の例と比べてもコスト削減にもなる。

とはいえ、最初のアーキテクチャと比べるとコスト増になるので、「コスト要件と可用性の要件を天秤にかけて選択すること」と堀氏はアドバイスする。

さらに堀氏はDBを使ったアーキテクチャの静的安定性も紹介した。RDSはスタンバイを他のAZに用意する。通常時はRDSのプライマリからスタンバイに同期レプリケーションして、プライマリの障害時は自動的にフェイルオーバーさせる。こうすることでコントロールプレーンに依存せず、静的安定性の高いアーキテクチャとなる。

最後に堀氏は以下のように述べ、セッションをまとめた。

「高いパフォーマンス、高機能、高可用性を実現するために静的安定性を考える必要があるので、今日の発表や記事を参考にしてほしい」（堀氏）

※参照記事：Amazon Builders' Library「アベイラビリティーゾーンを使用した静的安定性」

アマゾンウェブサービスジャパン合同会社
https://aws.amazon.com/jp/careers/