kdnakt blog

hello there.

The Amazon Builder's Libraryを読む:『シャッフルシャーディングを使ったワークロードの分離』

第11回のオンライン輪読会に備えて読んだ内容を自分なりにまとめておく。

今回の記事はこちら。

 

aws.amazon.com

   

 

[期待/予想する内容]

この記事の目次は次のとおりである。

 

シャッフルシャーディングってなんの話だろう、と思ったらDNSとかRoute 53の話なのか。シャーディングというとDynamoDBのプライマリキーベースでの分散を思い出すが、そういう話だろうか。

 

DNSホスティングの対応開始」……これは単にドメインを設定できるサービスを提供し始めましたよ、というだけかな?シャッフルシャーディングがなぜ必要になったか、という話の前段。

 

DDoS攻撃への対処」……DNSホスティングを始めるということは、すなわちDoS攻撃DDoS攻撃をうけることに繋がる訳で……それをなんとか防ぐ、捌く、軽減するためにシャッフルシャーディングが必要だった、ということだろうか。

 

「シャッフルシャーディングとは?」……ストレートにシャッフルシャーディングの説明。シャーディングは一定のアルゴリズムでデータを分散させるわけだから、さらにそれをシャッフルして、ランダムな要素が加わる、ということだろうか。ランダムにするとどうしてDDoS攻撃に有効なんだろう?

 

Amazon Route 53とシャッフルシャーディング」……Route 53に適用する際に何か特別なポイントがあったのだろうか。気になる……!

 

[記事の要約]

次に、実際に記事を読んだ内容を箇条書きでまとめる。

 

DNSホスティングの対応開始

 

DDoS攻撃への対処

  • DNSUDPを利用しておりリクエストが偽装されやすい
  • DNSはビジネス上重要なインフラなので、攻撃対象になる
  • 対策1:サーバーの容量を巨大にする(攻撃側と比べてコストがかかりすぎる)
  • 対策2:トラフィックの取り消しを高速で行う(ネットワークアプリケーションに特化している)
  • 対策3:シャッフルシャーディング(世界規模のDNSを妥当な規模のリソース、コストで実現できる)

 

シャッフルシャーディングとは?

  • シャーディングなし:ワーカーがすべて同じシャード(グループ)に属する
    • DDoS攻撃を受け、ワーカーが1台停止すると他のワーカーに負荷がかかり順次停止していく
  • 標準的なシャーディング:ワーカーを複数のシャードに分ける
    • ユーザーごとに属するシャードを決定する
    • リクエストに対応できるワーカー数が減ってはいるが、攻撃の影響範囲も減っている
    • 例:4シャードに分けて1シャードのみ影響をうけるなら、25%のみ影響をうける
    • https://d1.awsstatic.com/legal/builders-library/Screenshots/two-workers-per-shard.b0e80613981ea97186a35a3dd6405a359378c194.png

  • シャッフルシャーディング
    • ユーザーAのリクエストをシャード1と2に、ユーザーBのリクエストをシャード2と3に……振り分ける
    • 特定のユーザーからのリクエストでシャードに問題が生じても、シャードを共有している別のユーザーは、他のシャードからサービスを受けられる
    • 8ワーカーの場合、28通りのシャッフルシャードが存在するので、通常の4シャードと比べて7倍効率が良い(ワーカーが増えるとその分効率が上がる)
    • https://d1.awsstatic.com/legal/builders-library/Screenshots/shuffle-sharding-example.93b3c956c983a3716870b2b0100cd109ce8afc80.png

 

Amazon Route 53 とシャッフルシャーディング

  • Route53では2048の仮想ネームサーバーを利用
  • 各ユーザーのドメインは4つのシャッフルシャードに割当:7億3千万通りのシャッフルシャード
  • 1つのドメインDDoS攻撃を受けても他のドメインには全く影響しない
  • 攻撃があった場合は特別なキャパシティを設けて隔離を行う

 

まとめ

  • 改良版の再帰シャッフルシャーディング:ユーザーの下のユーザーも分離できる
  • シャッフルシャーディングは既存リソースに追加コストなしで利用できる改善策

 

[予想のふりかえりなど]

通常のシャーディングは理解していたつもりだけど、確かにそれだけだとDDoS攻撃で潰れてしまうんだな……そしてそれを追加のリソースコストなしでこんなに効率的に跳ね返すことができるなんて。ロジックというか、アルゴリズムってすごいと思った。

 

攻撃コストの何万倍もサーバー費用がかかるということを考えると、7倍程度のシャッフルシャーディングでは弱いよな、と思ったけど、サーバーの台数が2000台まで増えると圧倒的に効率が良くなっていて驚いた。

 

ただ、シャードをシャッフルするためのリクエストの識別を行うには、追加のリソースコストがかかるような気がする。既存リソースを増強する必要がないのは確かにその通りだけど、追加コストなしの対策というのはちょっと言い過ぎかな、とも感じた。実装してみないとなんともいえないけど。

 

内容と直接的に関係はないのだけれど、これまでに読んできた記事と比べて、この記事は誤字脱字や意味の通らない翻訳が圧倒的に少なかった気がする。良い。

 

[まとめ]

  • 「The Amazon Builder's Library」の『シャッフルシャーディングを使ったワークロードの分離』を読んだ
  • 標準的なシャーディング、シャッフルシャーディング、再帰シャッフルシャーディングを利用するとシャーディングなしの場合と比べて効率的にDDoS対策ができる
  • シャッフルシャーディングはRoute 53など様々なサービスで実装されている

 

これで11/13記事を読んだことになる。あと2つ!

引き続きAmazon Builder's Library読んでいくぞ。