Lv1から始めるWebサービスのインフラ構築

Editor's Notes

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