大規模分散システム ”Amazon Web Services”の使い方

橋本 幸司 Software Development Engineer

Amazon Web Services

Agenda

!   Amazon Web Services (AWS)の概要 !   大規模分散システム“AWS”の使い方

•  Asynchronous IO •  Retries with Exponential Backoff •  Idempotency •  Eventual Consistency

!   まとめ

2

大規模分散システムの特徴

!   大量のリクエスト・大規模データを処理するために、多くのコンピュータリソースを使用

!   システム内では常に部分障害が発生している •  一時的な障害 •  永久的な障害

!   システム全体の正確かつ詳細な状態を一元的に把握するのが困難

3

これらの問題を解決する仕組みをユーザに対し透過的に実現するのは困難

大規模分散システムにおける要素技術

!   1. Asynchronous IO

!   2. Retries with Exponential Backoff

!   3. Idempotency

!   4. Eventual Consistency

4

1. Asynchronous IO（非同期API）

!   多くのユーザから送られる大量のリクエストを公平かつ効率良く処理したい

5

処理は完了していないが ユニークIDを即時レスポンス

APIリクエスト

APIレスポンス

処理 リクエスト

処理 リクエスト

リクエストキュー APIサーバ群

バックエンド サーバ群

Asynchronous IO（API）の利点

!   ユーザ側の利点 •  アプリケーションがブロックされない

!   サーバ側の利点 •  スケーラブルかつ高可用なバックエンド •  APIを停止させることなくバックエンドを容易にメンテナンス可能 •  少ないAPIサーバキャパシティで多くのリクエストを受付可能 •  リクエストの処理順序やリトライ等の制御が容易

6

非同期APIの例：Amazon EC2

!   EC2 (Elastic Compute Cloud) !   EC2インスタンス起動： RunInstances

•  EC2インスタンスIDが即座に返される

•  実際にEC2インスタンスがAWSクラウド内で利用可能になるのは数分後

!   EC2インスタンスの状態問い合わせ： DescribeInstances •  レスポンス PENDING | RUNNING | SHUTTING-DOWN | TERMINATED

7

非同期APIの例：Amazon ELB

!   ELB (Elastic Load Balancing) !   バックエンドインスタンスの登録：RegisterInstancesWithLoadBalancer •  実際にバックエンドインスタンスがロードバランサーに登録されるの

は数秒後

!   バックエンドインスタンスの状態問い合わせ： DescribeInstanceHealth •  InService | OutOfService

8

非同期API - AWS API

!   大きく２種類のカテゴリ •  非同期Mutating API – AWSリソースに変更を加える

例：RunInstances, RegisterInstancesWithLoadBalancer

•  問い合わせAPI – AWSリソースの状態を問い合わせる 例：DescribeInstances, DescribeInstanceHealth

!   AWSユーザ側のプログラミングモデルは、問い合わせAPIを用いたポーリングが基本

9

ELBおよびSQSを用いた非同期API

10

APIリクエスト

APIレスポンス

処理 リクエスト

処理 リクエスト

APIサーバ群 バックエンド サーバ群

Auto scaling Group

AZ１

AZ２

AZ３ Auto scaling

Group

AZ１

AZ２

AZ３

Amazon SQS Amazon ELB

2. Retries with Exponential Backoff

!   Exponential Backoff •  リトライの間隔を指数関数的に増加させる

例：１秒後、２秒後、４秒後、８秒後、、、 •  長期障害発生時にシステムへの不必要な負担を軽減

!   大規模分散システム内では常に部分障害（特に一時的）が発生している •  障害発生時にいちいちシステムを止めていては高可用性を実現でき

ない

!   リトライにより後に成功する可能性が高い

11

AWS API利用におけるリトライの指針

HTTP Status Code リトライ 200 (OK) N/A 400 (Client Error) 非推奨（回復の見込みなし） 500 (Server Internal Error) 推奨 503 (Server Unavailable) 推奨

12

3. Idempotency（冪等性）

!   「ある操作を１回行っても複数回行っても結果が同じであることをいう概念」 - ウィキペディアより

!   例えば、サーバ側でAPIリクエストは受理されたが、何らかの理由でクライアント側でAPIレスポンスが消失した場合 •  クライアントはリトライ（APIリクエスト再送）

•  Idempotencyあり→障害回復

•  Idempotencyなし→回復不能（すなわち永久リトライ）

13

1. APIリクエスト

3. APIレスポンス APIサーバ

2. APIリクエスト 受付完了

Idempotencyの例：EC2

!   EC2インスタンス起動API： RunInstances

!   同一のトークンを与える限りIdempotencyが保証される !   同一のトークンにもかかわらず、入力パラメータが異なる場

合、クライアントエラー

14

%ec2-run-instances ami-b232d0db -k gsg-keypair --client-token 550e8400-e29b-41d4-a716-446655440000

Idempotencyの例：ELB

!   全てのELB APIはIdempotencyを提供

!   バックエンドインスタンス登録API：RegisterInstancesWithLoadBalancer

!   ロードバランサー名がトークンの役割 •  例外：DeleteLoadBalancer* API群

15

%elb-register-instances-with-lb MyLoadBalancer -i i-1a2b3c4d

余談：Exception論争（？）

!   チェック例外：プログラマはExceptionを処理するコードを書かなければならない

!   非チェック例外：その必要なし

!   大規模分散システム内では常に部分障害（特に一時的）が発生している •  Exception発生時にいちいち例外処理していてはクリーンなコードを

かけない •  大抵の場合、最終的にRetries with Exponential Backoff

16

try { 　　x = API_call(y, z); } catch (API_Exception e) { // 例外処理 }

Exception: AWS SDKの場合

!   AWS SDKで提供されているExceptionは全て 非チェック例外

17

4. Eventual Consistency

!   理想的なconsistencyモデル – あるデータがupdateされた場合、その後全てのread操作においてそのupdateが見える

!   現実には、データを複製し複数のストレージに格納することにより、消失を防ぐ

!   全ての複製にデータのupdateを反映するのに時間がかかる •  CAP Theorem（次のページ）

!   Eventual Consistency – 一定期間データのupdateがなければ、最終的に全ての複製にupdateが反映され、データの一貫性が保たれる

18

CAP Theorem

! Consistency, Availability, Network Partitioning耐性を同時に満たす事は不可能

19 Eric Brewer, PODC Keynote, 2000より引用

Eventual Consistencyの例: Amazon S3

!   データを複製し、複数のデータセンタにある複数のストレージに格納 •  99.999999999%の耐久性

!   Amazon S3におけるデータconsistencyモデル •  新規データを作成後、read操作において“データが存在しない”と返さ

れるかもしれない（US Standardの場合のみ） •  データをupdate後、read操作においてupdate前の古いデータが返さ

れるかもしれない

20

Eventual Consistencyの例：EC2

!   EC2インスタンス起動API：RunInstances •  インスタンスIDが返される

!   EC2インスタンス状態問い合わせAPI： DescribeInstances •  入力パラメータ：インスタンスID

! RunInstancesコール直後に、返されたインスタンスIDを基にDescribeInstancesをコールするとInvalidInstanceID.NotFoundが返されるかもしれない

!   Retries with Exponential Backoff推奨

21

Eventual Consistencyの例：SQS

!   キューの状態問い合わせAPI： GetQueueAttributes •  キュー内のメッセージ数： ApproximateNumberOfMessages

!   システム全体の正確かつ詳細な状態を一元的に把握するのが困難

22

まとめ

23

大規模分散システム “Amazon Web Services”

!   大規模分散システム内では常に部分障害（特に一時的）が発生している •  障害発生時にいちいちシステムを止めていては高可用性を実現でき

ない

!   高可用なシステムを構築するための４つの要素技術 !   ユーザに対し透過的に高可用性を実現するのは困難

!   大規模分散システムの特徴・要素技術を理解し、効果的にAWSを使ってください

! AWSを用いて高可用なシステムを構築するヒントになれば幸いです

24