[レポート] アマゾンの回復性のあるシステムを作るアプローチ DOP342-R #reinvent

[レポート] アマゾンの回復性のあるシステムを作るアプローチ DOP342-R #reinvent

AWS re:Invent 2019 DOP342-R - [REPEAT] Amazon's approach to building resilient servicesのセッションレポートです。
Clock Icon2019.12.04

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS re:Invent 2019 DOP342-R - [REPEAT] Amazon's approach to building resilient servicesのセッションレポートです。アマゾンで回復性のあるシステムを作るアプローチについて解説していました。

セッション情報

登壇者

Marc Brooker - Senior Principal Engineer, Amazon Web Services

概要

One of the biggest challenges of building services and systems is predicting the future. Changing load, business requirements, and customer behavior can all change in unexpected ways. In this talk, we look at how AWS builds, monitors, and operates services that handle the unexpected. Learn how to make your own services handle a changing world, from basic design principles to patterns you can apply today.

動画

スライド

https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Amazon's_approach_to_building_resilient_services_DOP342-R1.pdf

レポート

アジェンダ

  • オーナーシップ : DevとOpsのループを近づける
  • 運用における安全性 : オペレーターが成功するように設定する
  • サービスの安定性 : スケールシステムに安定性とは何を意味するのか
  • ジッター : どのようにランダム性は安全性を追加できるか

オーナーシップ

  • 機能を追加する -> 失敗する -> 原因を分析する -> 習慣を変える
  • リスクとは?
    • 動きが遅くなる
    • チケットの処理時間が延びていく
  • AWSではどうしているのか
    • 自分たちで作ったものを動かす
    • 上級エンジニアはビルダーである
    • ビジネスとテクノロジーを理解し、全員が運用に関する責任を持つ
    • COEはポストモーテム。全員がリスクを理解している
  • 小さなチームと強いオーナーシップ
    • 頻繁にデプロイする。
    • 問題を深く分解する。ヒューマンエラーなのかとか。そういう仕組を作る。
  • ループを近づける仕組みを持つ
    • 原因分析の対応をエンジニアではなくオペレーションチームにするとループしなくなる。

運用における安全性

  • なぜ、またどのようにオペレーターは彼らが知らなかったデザイン上の失敗を補償すべきなのか
    • これは非常によい問い
  • 学習環境における親切さと意地悪さ
    • 親切さ : 学ぶほど良くなる
    • 意地悪さ : 深い理解がないと間違ったことをする
  • システムを親切に作る
    • オペレーターが簡単に予測できるようにする
  • AWSではどうしているのか
    • 正直な分析
    • COEはオペレーターのエラーとして扱わない
    • レビューは上級エンジニアが行う
  • オペレーターに文句を言うのは簡単
    • リーダーシップはこのような考えを拒否しなければならない

サービスの安定性

  • 犬が屋根に登って滑り落ちる
    • 滑り落ちないように、支える力が必要
  • 分散システムは同じ問題をもつ
    • システムが過負荷になることで問題が拡大する
  • AWSではどうしているのか
    • キューサイズを制限
    • リトライを制限
    • エクスポネンシャルバックオフ

ジッター

  • ランチで店が混む
    • 12:00 : どんどん人が来てキューが詰まる
    • 12:15 : キューが非常に長く伸びる
    • 12:30 : 誰も待っていない
  • 分散システムは同様の問題を持つ
    • スパイク
  • ジッター
    • ランダムの一種
    • randint(0, base * 2 ** attempt)
  • AWSではどうしているのか
    • バックオフがあるなら常にジッターが存在する
    • 定期的な仕事があるなら常にジッターが存在する
    • 全ての仕事でジッターを考慮する

重要なポイント

  • 成功には技術だけでなく文化が必要

感想

AWSを提供しているAWSがどのように回復性のあるシステムを実装しているのか興味を持って参加したのですが、思った以上に普通というか当たり前のことを言っていると思いました。結局、実践できるかどうかが鍵なのだと思いました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.