Amazon Builder's Libraryを読んでみた

昨年のre:Invent 2019で発表されたAmazon Builder's Libraryを一通り読んでみました。通勤電車で読んでいたのですが、途中で冬休みに突入してしまい少し時間がかかってしまいました。途中で日本語にも対応していることに気付いたのですが、折角なので全て英語で読んでみました。

aws.amazon.com

Amazonにおける大規模分散システムの開発で得られたノウハウが公開されているのですが、昨今マイクロサービスの普及もあり、Amazonのような規模でなくとも分散システムに関するノウハウが重要になりつつあります。もちろんAWSのインフラや規模感に依存する部分も多々見られるものの、大規模な分散システムを運用した上で得られる知見というのは得難いものですし、一般論として参考になる部分も多く、とても有用なコンテンツだと思います。

全体を通して共通して述べられていたのは以下のような点です。

  • 複雑な仕組みはなるべく避ける
    • 複雑な仕組みにはテストが難しくなったり、トラブル時により状況を悪化させるリスクもあるので、きちんとメリット・デメリットを検討した上で本当に必要な場合のみ採用すること。また、すでに検証済みのライブラリなどは存在するのであればそれを使用し、車輪の再発明は避けること。
  • できるだけメトリックを取る
    • 何かしら判断を下す際に判断材料となるメトリックが必要。トラブルシュート時なども事前に適切なログ、メトリックが出ていると助けになる。具体的にどのようなログを取るべきかは各記事で説明されていますし、総論としてのロギングに関する記事もありました。

基本といえば基本ですが、どの記事でも繰り返し述べられていたのでやはりこういう部分が大事なんだなということを再確認させられました。

個人的には以下の記事が面白かったです。

  • Avoiding fallback in distributed systems
    • トラブル時のフォールバックはテストが難しい上に問題があってもすぐに発覚しないことが多いなどデメリットが大きいので避けるべきという話。もちろんケースバイケースだとは思うのですが、何も考えずに気軽にフォールバック処理を埋め込んでしまうのはよくないなぁという気付きがありました。
  • Leader election in distributed systems
    • Leader ElectionはカナリーデプロイやA/Bテストなどのための部分デプロイと相性が悪いというのは言われてみればという感じ。システムを冪等に作っておくことでトラブル時など複数のLeaderが存在する状態になってしまっても問題ないようにしておくなど、なるほどと思う点が多かったです。
  • Using load shedding to avoid overload
    • 高負荷時にキャパシティを超えたリクエストを拒否することで受け付けたリクエストのレイテンシを守るという手法。ヘルスチェックやオートスケーリングとの競合など気を付けないといけない点が多く実際にはなかなか扱いが難しそうですが、そういう部分も含めて興味深い記事でした。
  • Workload isolation using shuffle-sharding
    • Route53でDDoS攻撃の影響を最小限に抑えるために考案されたShuffle Shardingという手法について。シャッフルしたユーザの組み合わせを複数シャードにアサインしておくことで攻撃を受けているユーザ以外に影響が出ないようにするというもの。Route53の開発秘話的な面もあり面白かったです。

前述の通り、各記事は日本語でも読むことができますが、恐らく機械翻訳と思われ、記事によっては意味がよくわからない箇所もあったので英語で読んだ方がいいかもしれません。1つずつの記事が適度な長さ(一部やや長めの記事もありますが)ですし、AWSユーザであれば見知った概念やキーワードも多いのでさほど詰まらずに読み進めることができると思います。

マイクロサービス時代のWeb開発では避けて通れない話題がコンパクトにまとめられていますので、まだご覧になっていない方は一度目を通されてはいかがでしょうか。FAQによると今後も定期的に記事が追加される予定とのことなので要チェックです。