Lv1から始めるWebサービスのインフラ構築
•Transferir como PPTX, PDF•
249 gostaram•70,123 visualizações
2014年9月9日開催の"AWS Cloud Storage & DB Day"で使用した講演資料です。 以下のURLからもダウンロードすることができます。 http://iy-h.com/03/aws-storage-day-2014-09-09.pptx
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (15)
Semelhante a Lv1から始めるWebサービスのインフラ構築
Semelhante a Lv1から始めるWebサービスのインフラ構築 (20)
Lv1から始めるWebサービスのインフラ構築
- 1. Lv1から始める Webサービスのインフラ構築 2014-09-09 AWS Cloud Storage & DB Day 株式会社マイネット 伊藤祐策
- 2. 自己紹介 名前伊藤祐策 勤務先株式会社マイネット 肩書アーキテクト 事業内容スマートフォン向けゲームの開発・運営 お仕事内容 ・自社ゲームタイトルのサーバーインフラ構築 ・アプリケーション開発 ・主にサーバーサイド設計（特にDB設計！）
- 3. 自己紹介 大好きなAWSサービスは？ 1位.Amazon DynamoDB 2位.Amazon S3 3位.Amazon CloudFront
- 5. 今日のお話はこんな人におすすめ Webサービスを作って スタートアップしたい人 ユーザー数1人から100万人までをAWSで！
- 6. もくじ 第一部 Lv1から始めるWebサービス 第二部 スケーラブルな構成にするには？ 第三部 DynamoDBの正しい使い方
- 8. シナリオ あなたはとあるWeb系会社のエンジニアです。 ある日、社長が突然こんなことを言い出しました。 「我が社もソーシャルゲーム事業に参入するぞ！」 一瞬目眩がしましたが、あなたは覚悟を決めてシス テム設計を開始しました・・・。 ※このシナリオは全てフィクションです
- 9. シナリオ サービスリリースまでのステップ 1. アプリケーション開発 2. 社内アルファテスト（ユーザー数１０人） 3. ベータテスト（同５００人～？？？） 4. 正式オープン（同１万人～？？？）
- 10. シナリオ 先輩社員の助言によりAWSを採用することは決定し ましたが、あなたはAWSは全くの未経験でした。 そこでまずはAWSのアカウントを取るところから始 めることにしました。 【最初の目標】 アルファテスト用の環境を構築する
- 11. Step1 アカウント取得 AWSアカウントを取得する ★ここがポイント 必ず２アカウント用意しよう！ ・本番環境用アカウント ・開発環境用アカウント（兼試験環境） テストや訓練に費用を惜しまないこと！
- 12. Step2 IAM IAMで子アカウントを作成する グループは以下の２種類を作る ・AWSコンソールにアクセスする「人間ユーザー」 → Administratorテンプレートをそのまま使う ・アプリケーションユーザー → 必要最低限のアクセス権限だけを付与する ※IAMを作ったらrootアカウントは封印しましょう
- 13. Step3 VPC VPCを構築する サブネットとゲートウェイを作成して関連付ける ★ここがポイント ・サブネットは適切に切る（後述） ・"Auto-Assign Pulibc IP"をONにする → EIPを使う数を節約できる
- 14. Step3 VPC サブネットはこんな分割方法がオススメ 10.1.0.0/17 ← まずは半分をAZ-aに 10.1.128.0/18 ← 残りを半分をAZ-cに 10.1.192.0/19 ← さらもう半分をAZ-a に 領域を使いきってしまうとあとで困る！
- 15. Step4 セキュリティグループ セキュリティーグループを構築する サーバーの役割種別ごとにセキュリティーグループ を１個作る。 【例】 ・Webサーバー 外部から80番、443番。内部から22番。 ・RDS(MySQL)サーバー 内部から3306番。
- 16. Step5 EC2 EC2インスタンスを作成する ★ここがポイント ・配置先AZに気をつけて！ → リザーブドインスタンスを買う時に困る → たまにインスタンスタイプが枯渇する ※AWSの営業の人に相談しよう ・セットアップが完了したらAMIをとっておこう！
- 17. Step6 EIP EIPを取得する 外部に公開するインスタンスのENIにアタッチする。 ★ここがポイント ・EIP取得数の制限に注意！（申請で解除可能） ・インスタンスタイプ別にも関連付け可能数の制限 がある
- 18. Step6 EIP 必要なEIPはいくつ？ 1個目一般公開サイト用 2個目運営管理サイト用 3個目メール配信サーバー用 4個目SSHゲートウェイサーバー用 だいたい4個もあれば十分なのです！
- 19. Step7 Route53 Route53でゾーン設定をする 取得したEIPをホスト名登録する ★ここがポイント ・メール送信するときはSPFの設定を忘れずに！ ・さらにEIPに対するメール送信制限解除申請も必 要なので一緒に済ませておこう！
- 20. システム構成図(Lv1) t2.micro 約2,000 円/月 PHP MySQL
- 21. シナリオ アプリケーションも完成に近づき、いよいよ一般 ユーザーへサービスを公開することにしました。 しかし先輩社員はこんなことを言いだしました。 「この構成でインスタンスタイプ 上げるだけじゃダメなの？」
- 22. 問題 この構成のままインスタンスタイプを上 げるだけでは商用環境としてダメな理由 を答えなさい。
- 24. Webサービスとは サービス アプリ ケーション＝ ＋ データ Webサービスは「生き物」です！
- 25. 保全性について 「アプリケーション」は subversionやgithub等にマス ターがあるので保全性が確保さ れている。
- 26. 保全性について 一方「データ」はEC2のEBS上に あるのである日突然失われる可 能性がある。 データが消失→ サービス終了！
- 27. 商用環境の最低ライン 「隕石が直撃しても大丈夫」 データセンターが１つ壊滅して もサービスを復旧できること。
- 28. システム構成図(商用Lv1) 約10,000円/月 db.m1.small db.m1.small t2.small Multi-AZ 配置 EIP AMI 同期
- 29. システム構成図(商用Lv2) 約13,000円/月 db.m1.small db.m1.small t2.small ログ出力 Multi-AZ 配置 EIP AMI S3 ELB 同期
- 31. システム構成図(隕石直撃前) db.m1.small db.m1.small t2.small ログ出力 Multi-AZ 配置 EIP AMI S3 ELB 同期
- 32. システム構成図(AZ壊滅後) db.m1.small db.m1.small t2.small ログ出力 Multi-AZ 配置 EIP AMI S3 ELB 同期
- 33. 問題 以下のAWSストレージ系サービスうち、 デフォルトでデータの保全性が確保され ているものはどれか？ S3 EBS DynamoDB RDS Multi-AZ ElastiCache
- 34. 解答 以下のAWSストレージ系サービスうち、 デフォルトでデータの保全性が確保され ているものはどれか？ S3 EBS DynamoDB RDS Multi-AZ ElastiCache
- 35. まとめ 「大事なデータ」は保全性が確 保されているストレージサービ スに保存しましょう。 データさえ生き残っていれば サービスは何度でも蘇ります！
- 36. この式は見覚えありますよね？ MTBF MTBF + MTTR A = A .......... 可用性 MTBF ... 平均故障間隔 MTTR ... 平均復旧間隔
- 37. まずはMTTRを∞にしない保証を作ること ・・・というお話でした。 MTBF MTBF + MTTR A = コレの件 A .......... 可用性 MTBF ... 平均故障間隔 MTTR ... 平均復旧間隔
- 38. 質問タイム 2分ほど休憩
- 40. シナリオ 保全性の確保された構成の構築方法はわかったので すが、この「商用Lv2」の構成ではベータテストの 負荷には耐えられそうにありません。しかし、ベー タテストでは何人のユーザーが押し寄せるのか全く 検討もつきません。 【次の目標】 想定以上の負荷が来ても すぐに対応できる環境を構築する
- 41. 用語おさらい 「スケーラブル」とは？ 1. 増大する負荷に容易に対応できる 2. 負荷に合わせて自動的に拡張される
- 42. 用語おさらい 「スケーラブル」とは？ 1. 増大する負荷に容易に対応できる ↑こっちの話をします 2. 負荷に合わせて自動的に拡張される ↑これはややこしいのでまた今度...
- 43. 用語おさらい スケールアップ ノードの性能を上げること ＝インスタンスタイプを上げること スケールアウト ノードの数を増やすこと ＝インスタンスを追加すること
- 44. 理想パターン ・EC2インスタンスを追加すると全体性 能があがる。 ・RDSのリードレプリカを増やすと全 体性能があがる。 ・DynamoDBの性能予約を買い足すと 全体性能があがる。
- 45. 将来が不安なパターン ・インスタンスタイプを上げると全体性 能があがる。 ・EBSのIO性能を上げると全体性能が あがる。 → コスト効率が悪くなる → 性能拡張に上限がある
- 47. スケーラブルな構成（基本形） EC2 EC2 EC2 マスターDB リードレプリカ ELB
- 48. スケーラブルな構成（基本形） EC2 EC2 EC2 DB書き込み負荷 スケールアップ マスターDB リードレプリカ ELB CPU負荷 DB読み込み負荷 スケールアウト スケールアウト
- 49. サーバー負荷の傾向と対策 ボトルネックになるのは いつだってデータベース負荷 ＼もう限界／ マスターDB
- 50. 各種ストレージサービス解説 Amazon RDS フルマネージドリレーショナルDB Amazon DynamoDB フルマネージドKVS型分散DB Amazon ElastiCache ただのキャッシュサーバ
- 51. Amazon RDS ここがすごい！ ・メンテナンスフリー！ 自動的に定期バックアップ AZ間でレプリケーション※Multi-AZ配置時 ・リードレプリカをボタン１発で作成！ 読み込み性能を簡単スケーリング
- 52. Amazon RDS ここは注意！ ・一度起動すると止められない 稼働停止＝データ削除 EC2のように休止ができない ・スケールアップ時にアクセス不可になる だいたい１０分～３０分くらい メンテナンスモード必須
- 53. リレーショナルDB特有の問題 マスターDBへの負荷は どうあがいてもボトルネックになる。 書き込み処理が激しいアプリケーションでは いずれ限界が・・・。 ...しかしそこへ救世主が登場！
- 54. Amazon DynamoDB ここがすごい！ ・メンテナンスフリー！ ・すごい耐障害性※3箇所以上に分散保存 ・性能予約課金 ・動的な性能調整が可能 ・負荷による性能劣化を起さない
- 55. Amazon DynamoDB Amazon DynamoDBは マスターDBへの書き込み負荷が ヤバい時の救世主！？
- 56. Amazon DynamoDB ここは注意！ ・一貫性のあるバックアップを動的にとれない 「一貫性」か「動的」のどちらかを諦める ・性能上限に達すると一時的にアクセス不可になる ちょっと余裕を持って予約する必要がある ・単純な機能しかない 集計とかは無理です
- 57. Amazon DynamoDB どう使うか？ 負荷分散のための補助データベースとして使う NoSQL初心者にはこちらがオススメ。 メインデータベースとして使う 鬼門。死ヲ覚悟セヨ。（※第三部で解説）
- 58. Amazon ElastiCache ここがすごい！ ・とにかく速い ※中身はただのMemcachedです。 ※でも最近Redisも対応しました！
- 59. Amazon ElastiCache どう使うか？ ・大事なデータの格納はNG ・ストレージの読み込み負荷を軽減 させるためのキャッシュとして使う
- 60. まとめ スケールアウト可能な構成をがん ばって構築しましょう。 しかし、それでもいつかはマスター DBの負荷が限界にくることでしょ う。
- 61. 質問タイム 2分ほど休憩
- 63. シナリオ 無事リリースされたサービスは幸運にも大ヒットし、 ユーザー数を急速に伸ばしていきました。しかしマ スターDBの負荷は増大し、インスタンスタイプを db.r3.8xlargeまで上げたのにも関わらず性能の限界が 来てしまいました。そこであなたが決断した最後の手段 とは・・・。 【次の目標】 DynamoDBを使ってピンチを乗り切る
- 64. Amazon DynamoDBとは何か ・分散データベースである。 ・Key Value Storeである。 ・NoSQLである。 ・スキーマレスである。 ・フルマネージド型サービスである。
- 65. Amazon DynamoDBの特徴 ・ハッシュキーを基に負荷が分散される。 ・読込性能、書込性能それぞれの予約し た性能量に対して課金される。 ・１レコードは64kBまで格納可能。 ※キー名も容量に含まれるので注意
- 66. 使い方別難易度 【Easy】 ユーザー単位で独立しているデータだけを DynamoDBに移行して補助的に使う。 【Nightmare】 全てのデータをDynamoDBに載せてメイン データベースとして使う。RDSは補助データ ベースとして使う。
- 67. テーブル設計の勘所 ★ここがポイント テーブル設計は プライマリーキーの設計が命
- 68. プライマリキー設計 プライマリキーの仕様 ・プライマリキーの形式は２種類から選べる 1. ハッシュキーのみ 2. ハッシュキー＋ レンジキー ・処理の分散はハッシュキーによって行われる ・レンジキーでのみ範囲検索が可能
- 69. プライマリキー設計 設計例1 ユーザー固有情報 HashKey : ユーザーID RangeKey : なし ・アカウント情報 ・プロフィール情報
- 70. プライマリキー設計 設計例2 ユーザーの対ユーザー関係 HashKey : ユーザーID RangeKey : 対象ユーザーID ・フォロー ・ブロック
- 71. プライマリキー設計 設計例3 ユーザーの行動履歴 HashKey : ユーザーID RangeKey : ログID ・ゲーム内アイテムの購入 ・攻撃コマンドの実行 ・etc
- 72. ログIDの作り方 ・ログの発生時刻から文字列で生成する。 ・乱数も混ぜるといいかも。 ・万が一衝突したらもう一度トライ。 例："2014090916301234" ※桁数は固定しましょう
- 73. プライマリキー設計 設計例4 ユーザーの所有オブジェクト HashKey : ユーザーID RangeKey : オブジェクトID ・所有カード ・投稿記事 ※オブジェクトIDはログIDと同じ方法で生成
- 74. プライマリキー設計 設計例5 ユーザー間関係情報 HashKey : ユーザーID+対象ユーザーID RangeKey : なし ・フレンド ※ユーザーIDは小さい方を先にする
- 75. シナリオ マスターDBへ一番書き込んでいたのは実は ユーザーの行動履歴でした。そこで、ユー ザー行動履歴をDynamoDBに移行させたと ころ、大幅に書き込み負荷が減って無事ピン チをのりきりました。めでたしめでたし。 おしまい ※面倒くさいのでここでシナリオは打ち切りです
- 77. リレーショナルDBの限界 レコード同士の整合性を保証する代償として、複数 のノード上で処理を分散できないという制約を受け ている。 整合性の保証
- 79. 整合性保証を失うということ 要するに 「トランザクション」 が使えなくなる
- 80. トランザクションが使えないということ 同時に２つ以上のレコードを 整合性をたもったまま 更新することができない
- 81. トランザクションがないとこうなる 100ゴールドする薬草を買います。 所持金1,000 G 薬草0 個
- 82. トランザクションがないとこうなる 所持金を-100 します。 所持金900 G 薬草0 個 -100
- 83. トランザクションがないとこうなる 薬草を+1 します。 所持金900 G 薬草1 個+1
- 84. トランザクションがないとこうなる ・・・がしかし、通信障害が発生 して更新に失敗してしまいました。 所持金900 G 薬草0 個+1
- 85. もし整合性保証があれば・・・ ロールバックしてしまえば所持 金も元に戻るのでユーザーの被 害はない。つまり、 ALL or Nothingが保証されている
- 86. ではどうするのか？ アプリケーション側で トランザクションを実装する そりゃ鬼門と言われても仕方がないですね
- 87. トランザクションの構図(RDBMS) アプリケーション トランザクション テーブルテーブルテーブル MySQL
- 88. トランザクションの構図(DynamoDB) アプリケーション トランザクション テーブルテーブルテーブル DynamoDB DynamoDB DynamoDB
- 89. トランザクションの作り方 ・更新処理の開始から完了までを１つのトランザ クションと捉える。 ・各レコードの更新には楽観的ロックを用いる。 ・全ての更新処理に冪等性を持たせる。 ・処理の途中で失敗したら最初からやりなおす。 ・結果が収束するまで何度もやりなおす。
- 90. 用語解説 楽観的ロック 【意味】読み込んだレコードを更新するとき、 他の並行プロセスによって変更がされてい ないことを期待して更新をする方式。 並列性を高めるためにとても重要な概念
- 91. 用語解説 CAS操作 【意味】Compare and Swapの略。更新対象 のレコードの状態が期待した状態のときの み更新を実行し、そうでない場合は何もしな い操作。 楽観的ロックに必要な概念
- 92. CAS操作をSQLで表すと UPDATE user SET status=1,updated_at=NOW() WHERE id=100 AND status=0 ※初期状態はstatus=0とする。
- 93. 用語解説 冪等性 【意味】ある操作を1回行っても複数回行っ ても結果が同じであること。 整合性を確保するためにとても重要な概念
- 94. 冪等性のある処理の作り方 処理済？ CASで 更新 完了 開始 更新失敗 読込 更新成功 NO YES
- 95. 冪等性のある処理の作り方 冪等性の確保された処理はいくつ連結して も冪等性を保てる。 function() ✔ function() function() function() ✔
- 96. 実装例 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 1,000G 薬草 0個 レコードを準備
- 97. 実装例 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 900G -100 ID:123 薬草 0個 所持金を更新
- 98. 実装例 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 900G ID:123 薬草 1個 +1 ID:123 薬草の数を更新
- 99. 実装例 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：完了 所持金 900G ID:123 薬草 1個 ID:123 完了済みにする
- 100. 実装例 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：完了 所持金 900G 薬草 1個 掃除して完了
- 101. SQSと組み合わせて使う 1. 依頼書をレコードとして作る 2. SQSへ依頼書IDが書かれたメッセージを発行 3. バックグラウンドでSQSからメッセージを受け取 り、結果が収束するまで何度も実行する。
- 102. 全体フローチャート 開始 依頼書 作成 キュー 発行 完了 開始 冪等処理 冪等処理 完了 エラー発生 エラー発生
- 103. ロールバック処理 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 1,000G 薬草 0個 レコードを準備
- 104. 別の並行処理が邪魔をする 所持金 1,000G ロールバック処理 更新依頼書 ID:123 所持金: -100 薬草: +1 薬草 99個 +99
- 105. ロールバック処理 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 900G -100 ID:123 薬草 99個 所持金を更新
- 106. ロールバック処理 更新依頼書 ID:123 所持金: -100 薬草: +1 所持金 900G ID:123 薬草 99個 +1 上限エラー 薬草の数を更新
- 107. ロールバック処理 失敗済みにする 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：失敗 所持金 900G ID:123 薬草 99個
- 108. ロールバック処理 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：失敗 所持金 1,000G +100 薬草 99個 所持金を戻す
- 109. ロールバック処理 薬草の数も一応処理 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：失敗 所持金 1,000G 薬草 99個
- 110. ロールバック処理 完了（状態収束） 更新依頼書 ID:123 所持金: -100 薬草: +1 状態：失敗 所持金 1,000G 薬草 99個
- 111. まとめ 分散DBをメインDBとして使う場合、 トランザクションの再実装をしなけ ればいけないので大変。 しっかりフレームワークを組んでか ら挑むことを強く推奨。
- 112. 質問タイム お疲れ様でした
Notas do Editor
- みなさんこんにちは。 「今日はLv1から始めるWebサービスのインフラ構築」と題しまして、 いろいろとお話をさせて頂きたいと思います。
- 軽く自己紹介させて頂きます。 伊藤祐策と申します。 株式会社マイネットという会社で働いています。 会社の事業内容としては、 スマートフォン向けゲームアプリを展開しておりまして、 そのなかのインフラ構築やサーバーサイド設計などを 主なお仕事としています。
- 一番好きなAWSのサービスはDynamoDBです。 今日はDynamoDBについて沢山お話させて頂きます。 あと、S3とかクラウドフロントとかも大好きです。
- まあでも青いアイコンのやつはだいたい大好きです。 これらについても沢山お話しようと思います。
- 今日のお話はこんな人におすすめです。 Webサービスを作って スタートアップしたい人 ユーザー数1人から100万人までをAWSで、 というテーマでお話をしていきたいと思います。
- 今回のもくじはこのような感じになっています。 各部１０分くらいで、途中で質問タイムを適宜はさんでいく予定ですので 話の中で疑問点があれば控えておいてください。
- それでは早速、 第一部「Lv1から始めるWebサービス」について お話をしていきたいと思います。
- 今回は、話の内容を理解しやすくするため、ちょっとしたシナリオを用意しました。 あなたはとあるWeb系会社のエンジニアです。 ある日、社長が突然こんなことを言い出しました。 「我が社もソーシャルゲーム事業に参入するぞ！」 一瞬目眩がしましたが、あなたは覚悟を決めてシステム設計を開始しました・・・。 もちろんこのシナリオは全てフィクションです。 今日お話する内容は、ソーシャルゲームはもちろん、 一般的なWebサービスにもお使い頂けるノウハウを 惜しむことなくお話していきたいと思います。
- さて、それでは早速、Webサービスの開発を開始してから リリースするまでの大まかな流れを考えてみましょう。 第一部では、先にリリースについてフォーカスをあててお話していこうと思います。 アプリケーション開発がある程度終わったら、本番環境を構築して社内のスタッフを集め、 ユーザー数１０人程度でアルファテストをすることになると思います。 これがLv1です。 続いてベータテストに移行して、いよいよ一般ユーザーの受け入れをしていきます。 この頃にはもう、スケーラビリティのことを考慮した構成にしてきたいですね。 このあたりは第二部で詳しくお話していきたいと思います。 そして、ベータテストを終えると正式オープンすることになりますが、 ここからはいよいよ生半可な構成では太刀打ちできなくなる可能性が出てきます。 このあたりについては第三部でじっくりお話していきたいと思います。
- 再びシナリオに戻ります。 先輩社員の助言によりAWSを採用することは決定しましたが、あなたはAWSは全くの未経験でした。 そこでまずはAWSのアカウントを取るところから始めることにしました。 最初の目標は「アルファテスト用の環境を構築する」です。 とはいっても、まだ開発が開始されていないので、技術検証の意味も兼ねての環境構築となります。
- Step1、まずはAWSアカウントを取得しましょう。 弊社の場合、１サービスにつきAWSアカウントを１つ用意するようにしています。 現在ゲームタイトルを３つ運用しているので、３アカウントを並行して運用しています。 それとは別に、開発環境用、兼試験環境のアカウントを１つ取得して使っています。 これは本番環境と同じ環境での動作検証をする時や、AWSコンソールの操作訓練等に使っています。 訓練とはいてEC2インスタンスを立てたりするので費用は発生しますが、 訓練費用を惜しむとあとで倍返しがくるのでケチらず予算をとってやっています。
- Step2、IAMで子アカウントを作りましょう。 AWSアカウントを取得すると、まずはルートアカウントが作成されます。 ルートアカウントは登録時のメールアドレスでログインします。 しかし、AWSコンソールは複数のスタッフが触ることになるので、 アカウントを共有する形にすると後々不便がでてきてしまいます。 そこで使うのがIAMです。IAMはルートアカウントに紐付いたサブアカウント群です。 IAMは大きく２種類に分類でき、「人間ユーザー」と「アプリケーションユーザー」の２つがあります。 「人間ユーザー」のほうはリアルな人間１名につき１ユーザーを発行してください。 エンジニアであれば Administrator 権限のテンプレートをそのまま使っても良いでしょう。 一方、「アプリケーションユーザー」ですが、こちらはアプリケーションからAWSの各種サービスを APIを使って操作するときに必要になるものです。 一般的なLAMPだけの構成では必要ないこともあります。 アプリケーションユーザーは、必要最低限の権限だけを付与するようにします。 たとえばS３の出し入れだけとか、DynamoDBへのアクセスだけ、といった感じです。 IAMユーザーをひと通り作成し終えたら、ルートアカウントは封印しておきましょう。 ルートアカウントを乗っ取られるとサービスは一巻の終わりです。
- Step３、VPCの作成をしましょう。 VPCとは仮想プライベートネットワークのことです。 昔はVPCを作らずともEC2の起動ができたのですが、今はもうできません。 LANやルータのセットアップをしてきた人ならば簡単に覚えられるので、 これを機に習得してしまいましょう。 やることは、プライベートネットワークのサブネット設計と、ゲートウェイの配置だけです。 ここでポイントなのは、サブネットをちゃんと考えて切ることと、オートアサイン パブリックIPをONにすることです。 オートアサイン パブリックIPをONにすると、EIPの使用数を節約することができます。 なお、EIPはデフォルトで５個までしか取得できません。５個以上は申請が必要となります。
- サブネットの切り方の例です。 大事なポイントは、全部の領域を使いきってしまうとあとで困るということです。 切り方については、特にこだわりがなければ半分づつ切るという方法を使うことをオススメします。 10.1のサブネットの場合、/16なので最初は16bit分の領域があります。 これを/17で切って、約3万2千の領域を「アベイラビリティゾーン a」に割り当てます。 AWSアカウントによっては「アベイラビリティゾーン a」ではなくbとかcになることもあるので注意してください。 この例ではaとcの組み合わせを前提としています。 続いて10.1.128を/18で切って約1万6千の領域を「アベイラビリティゾーン c」に割り当てます。 さらに残りの10.1.192を/19で切って再び「アベイラビリティゾーン a」に割り当てます。 １つ目のサブネットはEC2インスタンスの領域に。 ２つ目と３つ目は後述するRDSの「マルチAZ配置」で使います。
- Step4、セキュリティグループを作成しましょう。 セキュリティグループとは、要するにファイアーウォールです。 iptables等のOS付属のファイアーウォールはこれがあれば要らないので切ってしまって構いません。 セキュリティグループはEC2インスタンスの役割種別ごとに作成して適用します。 たとえばWebサーバーであれば、外部から80番と443番を開けておきます。 SSH経由でメンテナンスすることも必要なので、プライベートネットワークから22番を許可しておきます。 RDSを使う場合にもセキュリティグループが必要なので、適宜作成しておきましょう。
- Step5、EC2インスタンスを作成しましょう。 ここでやっとEC2インスタンスを作成することができます。 前置きが結構長かったですが、 IAM、VPC、セキュリティーグループ、 どれも必修なので必ず習得しておきましょう。 さてEC2インスタンスの起動するときに注意しなければならないのが、 配置先のアベイラビリティゾーンです。 アベイラビリティゾーンとは、データセンター、つまり物理的な場所のことです。 アベイラビリティゾーンはどのアカウントからでも最低2つは利用可能なのですが、 どちらか一方をメインと決めて利用しないと、リザーブドインスタンスという 割引制度を利用するときに困ります。 また、インスタンスタイプが枯渇して起動できないこともごくまれですが起こります。 事前に営業担当をつけて相談しておくと、設備に余裕のあるアベイラビリティゾーンを教えてもらいます。 どうしてもインスタンスタイプの枯渇を回避したければ、リザーブドインスタンスを購入しておきましょう。 購入した分だけは必ず起動できることが保証されます。 最後に、セットアップが完了したEC2インスタンスは、一度シャットダウンしてAMIをとっておきましょう。 AMIをとっておけば、同じセットアップ内容のEC2インスタンスを複数起動したり、 万が一EC2インスタンスが起動できなくなったときにAMIから起動しなおすことが可能です。
- Step6、EIPを取得しましょう。 EIPとはグローバルIPアドレスのことです。 EIPを取得して、各インスタンスの仮想ネットワーク・インターフェースにアタッチすることで利用可能になります。 先ほども説明しましたが、EIPはデフォルトで５個までしか取得できません。 ５個以上が必要であれば申請フォームから制限解除申請を送る必要があります。 また、インスタンスタイプ別にもEIPのアタッチ数制限があります。 たとえばマイクロインスタンスだとEIPは１つしか付けることができません。 思わぬトラップにはまらないよう、事前に公式ドキュメントを確認しておきましょう。
- ところでEIPについてですが、さて一体いくつあれば十分なのでしょうか。 弊社事例だとこんな感じです。 一般公開サイト用 運営管理サイト用 メール配信サーバー用 SSHゲートウェイサーバーというメンテナンス用の裏口の４つです。 だいたい４つもあれば足りるはずなのですが、 もし５個以上使うような場合はサポート窓口に相談して 代替手段がないか聞いてみましょう。
- Step７、ルート５３の設定をしましょう。 Amazonルート５３はDNSホスティングサービスです。 AWSを使うのであれば、DNSサーバーのホスティングはルート５３を使いましょう。 各種AWSサービスとの強力な連携機能があるので使わない手はありません。 ルート５３でゾーン設定をしたのち、さきほど取得したEIPをここで登録します。 ここでのポイントですが、メールを送信するサービスであればSPFの設定と、 さらにEIPごとのメール送信制限解除申請も行っておきましょう。 多くの人がこれを忘れて痛い目を見ています。 申請はだいたい２～３日程度で通りますが、追加料金等はかからないので早めに済ませておきましょう。
- 以上を踏まえた上で作られたシステムの構成はこのようになります。 EC2インスタンスはt2.microで、直接EIPを付与してインターネットからの通信を受け止める形にしました。 月額2000円程度の非常にマイクロな構成です。 ユーザー数10人程度であればこのくらいで十分でしょう。
- アプリケーションも完成に近づき、いよいよ一般ユーザーへサービスを公開することにしました。 しかし先輩社員はこんなことを言いだしました。 「この構成でインスタンスタイプあげるだけじゃダメなの？」
- ここで問題です。 この構成のままインスタンスタイプを上げるだけでは商用環境としてダメな理由を答えなさい。
- 答えは「データの保全性が確保されていないから」です。
- そもそもWebサービスとは、このような２つの要素から成り立っているものなのです。 「アプリケーション」と、「データ」。 アプリケーションというのはプログラムはもちろん、サーバーそのものやサーバー構成、サーバーコンフィグ等も含まれます。 一方でデータというのは、サービスインから蓄積されてきた全てのユーザーデータです。 これを万が一失ってしまうと、ユーザーからの信用を失ってしまい、 二度とサービスを再開させることはできなくなってしまいます。 アプリケーションを肉体とすれば、データは魂です。つまり、Webサービスは生き物なのです。
- さて、この２つの保全性について、それぞれ考えてみましょう。 アプリケーションの部分は今であればsubversionやgithub等の 保全性がある程度確保された場所に置かれているので、 万が一構築したサーバー達が吹き飛んでしまってもリストアが可能です。
- 一方で、Webサービスの魂である「データ」は、 先ほどの構成ではEC2のEBS上に置かれていました。 EBSはデータの保全性を保証していないので、 ある日突然消失することもありえるのです。 万が一消失したときは、即サービス終了で再起不能に陥ってしまいます。 何百万もの開発費をかけて作り上げたものが、ある日突然無価値になってしまったら 会社はいったいどうなってしまうのでしょうか？ちょっと想像してみてください。
- というわけで、商用環境としての最低ラインはこのように設定するわけです。 「隕石が直撃しても大丈夫」 商用環境として運用するのであれば、 データセンターが１つくらい壊滅したとしても サービスをすぐに復旧させて再開できる状態を目指しましょう。
- 改めて、商用環境としてのLv1の構成はどのようになるのか考えてみましょう。 大事なポイントはデータを置く場所であるデータベースを RDSのマルチAZ配置にしておくことです。 マルチAZ配置にしておけば、リアルタイムにデータセンター間での レプリケーションが行われ、片方が突然消失しても データの損失は最小限に留めることができます。 もうひとつ大事なのは、EC2インスタンスをAMIとして保存しておくことです。 AMIはS3上に保存されるので、 こちらもデータセンターが１つ壊滅したくらいでは消失することはありません。
- もう少しがんばって、Lv2の構成がこちらになります。 さきほどの構成にELBを追加して、ログの保存をS3に出力させるようにします。 ELBに限らず、あらゆるログはトラブル発生時の大事な資料となります。 得られたログはとりあえずS3に保存しておく習慣をつけておきましょう。
- では早速、データセンターに隕石をぶち当ててみましょう。
- さきほどの構成が・・・。
- このように壊滅してしまいました。 この構成図のうち、バツ印は消失してしまったものです。 一方、マルになっているところは 複数のデータセンター間で保全性が保たれているおかげで 無事であることが保証されているもの達です。 これだけ残っていればサーバーを再構築して、 再びサービスを再開させることが可能なわけです。 多少ダウンタイムは発生しますが、 隕石が落ちたということで言い訳くらいは効くでしょう。 隕石が落ちても１日以内に復旧できるのであれば十分優秀です。
- ではここで問題です。 これらのAWS各種ストレージサービスのうち、 デフォルトで保全性が確保されているものはどれでしょう？ Amazon S3 Amazon Elastic Block Store Amazon DynamoDB Amazon RDS Multi-AZ配置 Amazon ElastiCache
- 正解はこちらになります。 S3、DynamoDB、RDSのMulti-AZ配置が正解です。 その他は保全性が保証されていないので、消えてはこまるような大事なデータは置かないようにしましょう。
- 第一部のまとめです。 「大事なデータ」は保全性が確保されているストレージサービスに保存しましょう。 データさえ生き残っていればサービスは何度でも蘇ります！
- 最後におまけです。 この式はみなさん、見覚えあるかと思います。 可用性 ＝ 全稼働時間 ÷ 平均故障間隔。
- よく話題になるのはMTBFを伸ばそうというお話なのですが、 冗長化技術はだいぶ枯れて普及もしてきたので今回は態々お話はしません。 一方でMTTRを短くしようとか、 ∞になるのを回避しようという話は 滅多に話題になることがないので 今回取り上げてみたという次第です。
- 以上で第一部はおしまいです。 ここでいったん質問タイムを取りたいと思います。 なにか聞きたいことがありましたら遠慮なく手を上げて下さい。
- それでは第二部いってみましょう！ 第二部のテーマは「スケーラブルな構成にするには？」です。
- 第一部では、保全性の確保された構成の構築方法はわかったのですが、 この「商用Lv2」の構成ではベータテストの負荷には耐えられそうにありません。 しかし、ベータテストでは何人のユーザーが押し寄せるのか全く検討もつきません。 そこで次の目標は、「想定以上の負荷が来てもすぐに対応できる環境を構築する」です。
- ここで用語をちょっとおさらいしてみましょう。 「スケーラブル」とはいったい何でしょうか？ 1. 増大する負荷に容易に対応できる 2. 負荷に合わせて自動的に拡張される
- 答えは１です。 ２のほうはだいぶレベルの高い話になるので、また別の機会にさせてください。
- もうひとつ用語のおさらいです。 スケールアップとは、ノードの性能を上げることです。 すなわち、EC2のインスタンスタイプを上げることです。 一方、スケールアウトとは、ノードの数を増やして全体性能の向上を図ることです。 これはつまり、ロードバランサー下のインスタンスを追加することとなります。
- スケーラブルな構成には、理想パターンがあります。 １つ目。EC2インスタンスを追加すると全体性能があがる。 ２つ目。RDSのリードレプリカを増やすと全体性能があがる。 ３つ目。DynamoDBの性能予約を買い足すと全体性能があがる。
- 一方で将来が不安なパターンもあります。 インスタンスタイプを上げると全体性能があがる。 EBSのIO性能を上げると全体性能があがる。 単一ノードの性能をあげると全体性能は当然あがるのですが、 コスト効率が徐々に悪くなってしまいます。 そしてさらに怖いのは、 一番上位のインスタンスタイプに到達してしまうと、 そこがシステムの限界となってしまう点です。
- つまり、スケーラブルなシステムとは、 システム構成をスケール「アウト」ができる形にすることです。 スケール「アップ」しかできない箇所を全て排除することができれば、 それは完璧なスケーラブル構成と言っても良いでしょう。
- 以上を踏まえた上で、スケーラブルな構成の基本形はこのようになります。 一段目にELBを置き、その配下にアプリケーションサーバーを複数台配置します。 さらにその奥にはリードレプリカを何台か備えたRDSを配置し、 各アプリケーションサーバーは、データの書き込みをマスターDBへ、 データの読み込みをランダムに選定したリードレプリカで行います。
- システムへの負荷は、大きく分けて CPU負荷、DB書き込み負荷、 DB読み込み負荷の３つに分類されます。 CPU負荷はEC2インスタンスのスケール「アウト」で対応します。 DB読み込み負荷はリードレプリカのスケール「アウト」で対応します。 一方、DB書き込み負荷はマスターDBのスケール「アップ」でしか対応できません。
- サーバー負荷の傾向として、 ボトルネックになるのはいつだってデータベースの書き込み負荷です。 巷の大規模サービスを運営している会社のエンジニア達は、 マスターDBへの負荷をどうするかで、大体いつも頭を抱えています。 あるエンジニアは垂直分散で対応しようとしました。 しかしデータの不整合に悩まされるようになりました。 あるエンジニアは水平分散で対応しようとしました。 しかしDBサーバーの障害で死ぬ思いをしました。 あるエンジニアはカサンドラを使って死にました。 あるエンジニアは東京なんとかを使いましたがどうなったのかは知りません。
- 話が暗くなってきたので、 ここでAWSのストレージ系サービスを簡単に紹介していきたいと思います。 Amazon RDS Amazon DynamoDB Amazon ElastiCache の３つについて順番に紹介しようと思います。
- Amazon RDS ここがすごい！ メンテナンスフリー！自動的に定期バックアップ！ あの面倒くさいバックアップ関連の処理を全部やってくれます。 そしてAZ間で自動的にレプリケーション。ただしMulti-AZ配置を明示的に指定する必要があります。 第一部でも解説したとおり、データの保全性を強力に担保してくれる機能です。 さらにリードレプリカをボタン１発で作成！ リードレプリカとは、マスターDBへの書き込みを リアルタイムに反映して作られるマスターDBの複製です。 多少の一貫性は落ちますが、それでも構わないデータはこちらから取得して 読み込み負荷を分散させることができます。
- しかし注意しなければならない点もあります。 まず一度起動すると停止ができません。 削除するまでずっと課金され続けてしまいます。 EC2であればインスタンスを停止している間は課金も停止するのですが、 RDSはそうはいかないので、よく考えてから建てなければいけません。 また、スケールアップするためにインスタンスタイプを変更すると、 一時的にアクセスできなくなります。 ちゃんとメンテナンスモードを用意してからスケールアップ作業を実施する必要があります。
- さらに、リレーショナルDB特有の問題もあります。 先ほど述べた通り、マスターDBへの負荷はどうあがいてもボトルネックになるのです。 しかし手立てがもう無いわけではありません。 きっとなんとかしてくれる救世主が存在します。
- Amazon DynamoDB AWSのすごい人が作ったすごい分散データベースです。 すごい点は沢山あるのですが、 なにより「負荷による性能劣化を起さない」 という所が一番すごいんです。 課金額さえ増やせば無制限に性能が上がるというすごいデータベースです。
- DynamoDBは確かにすごい奴です。 マスターDBへの負荷がどうしようもなくなったときの 救世主となってくれるかもしれません。 これについては第三部で詳しく解説します。
- 一方、DynamoDBには弱点もあります。 まず、バックアップが簡単にとれません。 「一貫性」か「動的」のどちらかを諦める必要があります。 また、課金額から決定された性能上限に達すると 一時的にアクセスできなくなります。 これらを想定した上でアプリケーションを書かないと あっというまにデータ不整合が発生します。 あと、集計などの複雑な処理はできないことです。 これは分散DBなので仕方ありません。
- さて、DynamoDBはどこにどう使ったらいいのでしょうか。 使い方は大きく２つに分けられます。 １つ目は負荷分散のための補助的なデータベースとして使うことです。 単純な読み書き処理しかしない箇所のストレージを DynamoDBに置き換えることで、マスターDBへの負荷の軽減を目論みます。 こちらは比較的リスクが少ないので、 NoSQL初心者にはオススメです。 一方、２つ目は、覚悟を決めてメインデータベースとして使うことです。 こちらはアプリケーションエンジニアに相当な力量が必要とされます。 生半可な技術力で挑むと火傷することは請け合いでしょう。 詳しくは第三部で解説します。
- 最後はElastiCacheです。 「エラスティキャッシュ」と読むので間違わないようにしましょう。 ぶっちゃけると中身はただのmemcachedなので、 とにかく速い以外の特徴はありません。 でも最近、Redisエンジンも使えるようになったそうです。
- とはいえ、あくまでも「キャッシュ」なので 大事なデータの格納はNGです。 まずは各種ストレージへの読み込み負荷軽減のために使いましょう。 memcachedもRedisも、とにかく速いのでレスポンスタイムの改善にも貢献してくれます。
- 第二部のまとめです。 スケールアウト可能な構成をがんばって構築しましょう。 しかし、それでもいつかはマスターDBの負荷が限界にくることでしょう。
- 以上で第二部はおしまいです。 ここでも質問タイムを取りたいと思います。 なにか聞きたいことがありましたら遠慮なく手を上げて下さい。
- ではいよいよ第三部です。 この節ではDynamoDBの正しい使い方についてお話しようと思います。
- ふたたびシナリオです。 無事リリースされたサービスは幸運にも大ヒットし、 ユーザー数を急速に伸ばしていきました。 しかしマスターDBの負荷は増大し、 インスタンスタイプをdb.r3.8xlargeまで上げたのにも関わらず 性能の限界が来てしまいました。 そこであなたが決断した最後の手段とは・・・。 次の目標は、DynamoDBを使ってピンチを乗り切ることです。
- 第二部でも紹介しましたが、DynamoDBとはこのようなデータベースです。 アプリケーション開発者視点では、 分散データベース、キーバリューストア、 NoSQL、スキーマレスという特徴を備えています。 インフラエンジニア視点だと、 フルマネージド型サービスであるという特長があります。
- DynamoDBで上手に負荷を捌きたければ、 このような仕様を知って置かなければいけません。 まず、負荷分散はハッシュキーを基に分散が行われます。 このため、１つのキーにアクセスが集中してしまうような作りにしてしまうと パフォーマンスを思うように稼ぐことができません。 ハッシュキーを上手に設計できるかが 高いパフォーマンスを実現できるかのカギとなります。 また、読み込み性能、書き込み性能はそれぞれ 課金額によって上限が決まる仕様となっています。 性能予約は「キャパシティーユニット」という １秒あたりのアクセス量で指定します。 予約した性能を超過した状態をおおよそ３０秒くらい持続させてしまうと、 性能超過エラーを返されて一時的にアクセス不能となってしまいます。 弊社の場合、１日のピーク値が７０％ラインになるように 余裕をもった予約をしています。 若干コスト効率が悪いですが、自前で分散DBを構築するよりは ずっと安く済んでいるので、あまり惜しまずに性能予約をしています。 あと細かいですが、１レコードには６４キロバイトまでしか入りません。 大きなデータを格納したいときはS3を利用するようにしましょう。
- 第二部でもお話しましたが、 DynamoDBはどのように使うかで難易度に大きく差が出ます。 ユーザー単位で独立しているデータで、 かつレコード同士の整合性を保つ必要がないものに関しては 比較的カンタンにDynamoDBへ移行することができるでしょう。 一方、全てのデータをDynamoDBへ格納して、 集計などの複雑な機能はRDSに任せるという使い方をする場合、 よりスケーラブルなシステムにすることが可能となる一方、 アプリケーションエンジニアは大変な思いをすることになるでしょう。
- ではいよいよテーブル設計のコツについてお話しようと思います。 大事なポイントは、「テーブル設計はプライマリキーの設計が命」ということです。
- DynamoDBのプライマリキーには以下の２パターンがあります。 １つ目はハッシュキーのみのパターン。 この場合、他のKVSと同じような使い方となります。 ２つ目はハッシュキー＋レンジキーのパターンです。 レンジキーを設定しておくと、範囲を指定して レコードを一括取得することができるようになります。 ただし負荷分散はあくまでもハッシュキーでのみ行われるので、 アクセスが集中しないようによく考えて設計する必要があります。
- ではテーブルの設計例をいくつか紹介していきます。 まずはハッシュキーに「ユーザーID」だけを使ったテーブルの例です。 アカウント情報やプロフィール情報等が適用例として考えられます。
- 次はハッシュキーに「ユーザーID」、レンジキーに「対象ユーザーID」を設定した例です。 Twitterで言うフォローやブロックといった、 ユーザーから他のユーザーへの一方的な関係情報を 保存するテーブルに適しています。
- 次はハッシュキーに「ユーザーID」、レンジキーに「ログID」を設定した例です。 これはユーザーの行動履歴を保存するテーブルに適したパターンです。 たとえば、ゲーム内でアイテムを購入したり、攻撃コマンドを実行した等です。 DynamoDBは行動履歴の保存に非常に適しており、このパターンはとても良く使われます。
- さて、ログIDについてですが、IDの作り方にも工夫があります。 DynamoDBにはオートインクリメントといった機能は備わっていないので、 シーケンシャルなIDを生成するのは苦手です。 そこで、日付と時刻から固定長文字列でIDを生成するという方法を取ります。 マイクロ秒や乱数も付け加えておけば、まず衝突するようなことはありません。 万が一衝突した場合は、再度生成してリトライすれば良いのです。 日付時刻からIDを生成しておくと、レンジキーの範囲検索を日付指定で 検索することができるようになって非常に便利です。
- 次は、行動履歴テーブルに似ていますが、今度はレンジキーに「オブジェクトID」を使うパターンです。 たとえばゲーム内でカードを新規に手に入れたとします。 このとき、カードの「オブジェクトID」を「ログID」と同じ方法で発行し、 レンジキーに指定してレコードを作成します。 こうすることで、ユーザーの「所有物」という概念を実装することができます。
- 最後の例は少し特殊です。 ハッシュキーとして、２つのユーザーIDを連結した文字列を使います。 これはユーザー間の関係情報、 たとえばフレンド関係といった情報を格納するテーブルに適したパターンです。 ２者の関係を１レコードにまとめることにより、 排他制御を簡単にすることができるようになります。 排他制御の方法についてはこのあと詳しく解説します。
- さて、シナリオもいよいよ大詰めです。 マスターDBへ一番書き込んでいたのは実はユーザーの行動履歴でした。 そこで、ユーザー行動履歴をDynamoDBに移行させたところ、 大幅に書き込み負荷が減って無事ピンチをのりきりました。 めでたしめでたし。 たいていのソーシャルゲームでは、ユーザーサポートで困らないために ユーザーが行ったあらゆる行動は全て記録しています。 よくアイテムが消失したとか、報酬がもらえなかったとかいうクレームが 頻繁にお問い合わせで来るのですが、このときユーザーのとった行動が 証拠として残っていないと真実が何なのかさっぱりわかりません。 そこで行動履歴を全て記録するのですが、これのせいでデータベースの 負荷が火を吹いてエンジニアが白目を剥くという例が跡を絶ちません。 せめてそこだけでもDynamoDBへ以降することができれば、 安心して眠れる日々を取り戻せるかもしれないので是非検討してみて下さい。
- さて、ここからは鬼門の入口となります。 DynamoDBをメインデータベースとして使いたければ、 ここからの話を理解した上で臨む必要があります。
- まずはおさらいです。 リレーショナルDBでは、レコード同士の整合性を保証していますが、 その整合性の代償として、複数ノードで処理を分散できないという制約を受けています。
- 一方、分散データベースでは、 レコード同士の整合性を放棄する代わりに、 複数ノードで処理を分担できる仕組みを獲得しています。
- 整合性の保証を失うこととは、すなわち、 「トランザクション」が使えなくなるということです。 MySQLでもOracleでもいいのですが、 「スタートトランザクション」と「コミット」と「ロールバック」を禁止された状態で アプリケーションロジックを実装することができるか考えてみて下さい。
- トランザクションが使えないということは、 複数のレコードを、整合性を保ったまま 更新することができないことを意味します。
- トランザクションがないとどうなるかちょっと考えてみましょう。 例えば、１００ゴールドを支払って、 薬草というアイテムを購入するシーンを想定してみます。 ここでは「所持金」と「アイテム所持数」という２つのレコードが存在することになります。
- まず、所持金をマイナス１００します。
- 次に薬草の所持数をプラス１します。
- しかし、処理の途中で通信経路に障害が発生して接続が切れてしまいました。
- もしここで整合性保証があれば、 ロールバックしてしまえば万事解決します。 整合性保証があれば、操作のオール・オア・ノッシングが保証されるのです。
- ではトランザクションが使えないのであれば、 一体どうすればいいのでしょうか。 答えは簡単で、アプリケーション側でトランザクションを実装するということです。 簡単とはいいましたが、実際には極めて面倒くさいです。 鬼門と言われても仕方ありません。
- いままでの構図はこのような形でした。 リレーショナル・データベースであるMySQLは、 トランザクションの機構を内部に備えています。 そのため、アプリケーションからは、 トランザクションの実装を特に意識することなく 読み書き操作をSQLで指示すればよいだけでした。
- しかしDynamoDBを使うとなると、 今度はトランザクションの機構をアプリケーション側で持つことになります。 すなわち、トランザクションの再実装を強いられるというわけです。 しかし具体的にはどう実装すれば良いのでしょうか。
- DynamoDBでトランザクションを作るには、以下の基本事項を守る必要があります。 まず、更新処理の開始から完了までを１つのトランザクションと捉えます。 各レコードの更新には楽観的ロックを用い、さらに全ての更新処理に「冪等性」を持たせます。 処理の途中で失敗が発生したら最初からやりなおし、結果が収束するまで繰り返します。
- さていくつか用語が出てきたので解説します。 まずは「楽観的ロック」ですが、 これは読み込んだレコードを基に 書き込み処理をする際、 他の並行プロセスによって 割り込んで書き込みがされていないことを 期待して更新を行う方式です。 もし割り込みで書き込みがされていた場合は 自分の処理を最初からやりなおします。 この楽観的ロックを実装するには、 データベース側に「キャス操作」という機能が必要です。
- CAS操作とは、 コンペア・アンド・スワップの略で、 更新対象のレコードの状態が 期待した状態と一致していたときだけ 更新を実行するという操作です。 DynamoDBはもちろん、memcachedでも CAS操作はサポートされています。
- CAS操作をSQLで表すとすればこんな感じになります。 当該レコードのステータスという値が 0のときだけ1に更新するというSQL文です。 このクエリを何回実行しても、 レコードは１回しか更新されないことに注目して下さい。
- 次に「冪等性」ですが、これは先ほどのCAS操作のように、 何回行っても結果が同じになるという性質を表した言葉です。 分散DBでデータの整合性を確保するために とても重要な概念です。
- 冪等性のある処理は、基本的にこのようなフローとなります。 レコードを読み込んで、処理済みならばスキップします。 未処理であればCAS操作を用いて更新し、更新に失敗したら最初に戻ってやり直します。
- 冪等性が確保された処理は、 いくつ連結しても全体で冪等性を保たれるという性質があります。 この性質を利用してアプリケーション実装を進めていきます。
- ではさらに詳しい例を解説します。 冒頭でお話した失敗例を、 今度はDynamoDBでちゃんと実装してみましょう。 まずはレコードを３種類準備します。 所持金とアイテム所持数はそのままですが、 ここで「更新依頼書」というレコードを新たに用意します。 このレコードはユーザーが「薬草を１個買う」という アクションを起こした時に作成し、 レコードをどのように更新するかが 全て指示として書かれたレコードです。
- まず、依頼書に従い所持金レコードを-100します。 このとき、依頼書のIDを所持金レコードに書き込んでおきます。
- 次に、薬草の所持数も＋１します。 同様に、依頼書のIDを書き込んでおきます。
- 最後に依頼書の状態を完了済みにします。
- 最後に各レコードに書かれた 自身の依頼書IDをクリーンアップして 処理は完了となります。
- ここまでの処理は、SQSと組み合わせて実装します。 SQSには、キューのメッセージが削除されるまでは 何度でも取り出しが可能という特徴があります。 この特徴を利用して、まず依頼書をレコードとして作成し、 そのレコードのIDを処理依頼としてSQSへキューイングします。 これをバックグラウド処理で１つづつ処理しますが、 処理結果が収束するまで何度でも実行されるように実装します。
- 全体のフローチャートはこのようになります。 ユーザーのアクションをトリガーとして、 一番左上の「開始」から処理が始まります。 原則、依頼書を作成してキューを発行したら いったんそこで、そのプロセスは処理を終えます。 あとはキュー処理で結果が収束するまで処理全体を繰り返します。
- では再びさきほどの例で、 途中で書き込みに失敗する場合のことを考えてみましょう。 まずはレコードを同じように準備します。
- しかし想定外の並行プロセスが、 薬草の所持数を上限である９９個に 更新してしまいました。
- しかしキュー処理は開始されてしまっているので、 所持金の徴収処理をはじめてしまいます。
- 所持金の徴収が終わった後に 薬草の数を更新しようとしたところ、 所持上限エラーが発生してしまいました。
- このとき、これ以上正常な処理を続行できない場合は トランザクションを中止して、 全てをロールバックさせます。
- 各レコードには更新依頼書のIDが書かれているので、 差し戻しをすべきレコードか否かが情報として残っています。 所持金レコードは-100したので、+100をして元に戻します。
- 薬草の所持数も元に戻す処理を一応しますが、 依頼書IDが書かれていないので 差し戻し処理をスキップすることができます。
- こうして無事ロールバック処理が完了しました。 ユーザーは自分の操作が反映されていないことに一瞬戸惑うでしょうが、 所持金は減っていないのでクレームになることはありません。 これでトランザクションをなんとか再実装することができました。
- まとめです。 分散DBをメインDBとして使う場合、 トランザクションの再実装をしなければいけないので大変です。 それでもやるというのであれば、 しっかりフレームワークを組んでから挑むことを強く推奨します。
- 講演は以上となります。ご清聴ありがとうございました。 以降、質問タイムとなりますのでご質問のあるかたは挙手をお願いします。