大 規 模 分 散 システム 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)! 多 くのユーザから 送 られる 大 量 のリクエストを 公 平 かつ 効 率 良 く 処 理 したい 処 理 リクエスト APIリクエスト 処 理 リクエスト APIレスポンス APIサーバ 群 処 理 は 完 了 していないが ユニークIDを 即 時 レスポンス リクエストキュー バックエンド サーバ 群 5
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! 大 きく2 種 類 のカテゴリ 非 同 期 Mutating API AWSリソースに 変 更 を 加 える 例 :RunInstances, RegisterInstancesWithLoadBalancer 問 い 合 わせAPI AWSリソースの 状 態 を 問 い 合 わせる 例 :DescribeInstances, DescribeInstanceHealth! AWSユーザ 側 のプログラミングモデルは 問 い 合 わせAPIを 用 いたポーリングが 基 本 9
ELBおよびSQSを 用 いた 非 同 期 API Amazon ELB Amazon SQS 処 理 リクエスト APIリクエスト AZ 処 理 リクエスト AZ APIレスポンス AZ AZ AZ AZ Auto scaling Group Auto scaling Group APIサーバ 群 バックエンド サーバ 群 10
2. Retries with Exponential Backoff! Exponential Backoff リトライの 間 隔 を 指 数 関 数 的 に 増 加 させる 例 :1 秒 後 2 秒 後 4 秒 後 8 秒 後 長 期 障 害 発 生 時 にシステムへの 不 必 要 な 負 担 を 軽 減! 大 規 模 分 散 システム 内 では 常 に 部 分 障 害 ( 特 に 一 時 的 )が 発 生 している 障 害 発 生 時 にいちいちシステムを 止 めていては 高 可 用 性 を 実 現 でき ない! リトライにより 後 に 成 功 する 可 能 性 が 高 い 11
AWS API 利 用 におけるリトライの 指 針 HTTP Status Code リトライ 200 (OK) N/A 400 (Client Error) 非 推 奨 ( 回 復 の 見 込 みなし) 500 (Server Internal Error) 推 奨 503 (Server Unavailable) 推 奨 12
3. Idempotency( 冪 等 性 )! ある 操 作 を1 回 行 っても 複 数 回 行 っても 結 果 が 同 じであるこ とをいう 概 念 - ウィキペディアより! 例 えば サーバ 側 でAPIリクエストは 受 理 されたが 何 らかの 理 由 でクライアント 側 でAPIレスポンスが 消 失 した 場 合 クライアントはリトライ(APIリクエスト 再 送 ) Idempotencyあり 障 害 回 復 Idempotencyなし 回 復 不 能 (すなわち 永 久 リトライ) 1. APIリクエスト 2. APIリクエスト 受 付 完 了 3. APIレスポンス APIサーバ 13
Idempotencyの 例 :EC2! EC2インスタンス 起 動 API: RunInstances %ec2-run-instances ami-b232d0db -k gsg-keypair --client-token 550e8400-e29b-41d4-a716-446655440000! 同 一 のトークンを 与 える 限 りIdempotencyが 保 証 される! 同 一 のトークンにもかかわらず 入 力 パラメータが 異 なる 場 合 クライアントエラー 14
Idempotencyの 例 :ELB! 全 てのELB APIはIdempotencyを 提 供! バックエンドインスタンス 登 録 API: RegisterInstancesWithLoadBalancer %elb-register-instances-with-lb MyLoadBalancer -i i-1a2b3c4d! ロードバランサー 名 がトークンの 役 割 例 外 :DeleteLoadBalancer* API 群 15
余 談 :Exception 論 争 (?)! チェック 例 外 :プログラマはExceptionを 処 理 するコードを 書 かなければならない! 非 チェック 例 外 :その 必 要 なし try { x = API_call(y, z); } catch (API_Exception e) { // 例 外 処 理 }! 大 規 模 分 散 システム 内 では 常 に 部 分 障 害 ( 特 に 一 時 的 )が 発 生 している Exception 発 生 時 にいちいち 例 外 処 理 していてはクリーンなコードを かけない 大 抵 の 場 合 最 終 的 にRetries with Exponential Backoff 16
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 耐 性 を 同 時 に 満 たす 事 は 不 可 能 Eric Brewer, PODC Keynote, 2000より 引 用 19
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! 大 規 模 分 散 システム 内 では 常 に 部 分 障 害 ( 特 に 一 時 的 )が 発 生 している 障 害 発 生 時 にいちいちシステムを 止 めていては 高 可 用 性 を 実 現 でき ない! 高 可 用 なシステムを 構 築 するための4つの 要 素 技 術! ユーザに 対 し 透 過 的 に 高 可 用 性 を 実 現 するのは 困 難! 大 規 模 分 散 システムの 特 徴 要 素 技 術 を 理 解 し 効 果 的 に AWSを 使 ってください! AWSを 用 いて 高 可 用 なシステムを 構 築 するヒントになれば 幸 いです 24