class: title, smokescreen, shelf, no-footer # クラウドコンピューティング<br><small>第11回 データの永続化</small> <div class=footnote> <small><small> 3年、秋学期、選択; 旧「オペレーティングシステム」; ;脚注はELや定期試験の範囲ではありません </small></small> </div> --- class: compact # <small>【復習】</small> <div class=footnote> <small><small> (脚注) どれだけ障害対策を考えられているか？で、エンジニアの腕が分かるというものです </small></small> </div> <small> - 「必要なときに」「必要な量」のITインフラやサービスを購入できることがクラウドの特徴 - ユーザ数に応じてWeb APIサーバを必要なだけ何台でも起動させ(られ)ます - 「ソーシャルゲーム」や「BLACk FRAIDAYなどの特売イベント」はクラウドが活かせる好例 - システム設計と運用では、きちんと障害対策を考えているか？が重要です - Web APIサーバをステートレスに作ると障害時にはデータが失われます - ショッピングを例にとると、ショッピングカートの情報や購入履歴が消えてしまいます </small> --- class: compact,img-right # <small>ショッピングサイトの全体像</small> <div class=footnote> <small><small> (脚注1) 1.は、「同じコンテンツを持ったサーバ群のどれか一つ」にユーザを誘導すればよいことに注意してください <br> (脚注2) 2.キャッシュシステムも3.RDBMSも障害に備えて冗長化されているシステムという想定です </small></small> </div>  <small> 1. ショッピングサイトにアクセスし、商品をいろいろ見て回ります 1. ショッピングカートに商品を入れます。 キャッシュシステムにカートの内容を保存します 1. 商品を購入した場合は、キャッシュではなく、きちんと履歴をRDBMS(いわゆるSQLサーバ)に(原則、永久)保存します </small> --- class: compact,img-right # <small>ステートレスなWeb APIサーバ群(図の1.)</small> <div class=footnote> <small><small> (脚注1) (本題ではないので演習ではやりませんが) 実際には、もっと多数の商品と、その商品の説明や画像のコンテンツを持っているはずです。 Amazonみたいに商品が1000万点とかあるなら違う作り方が必要ですが、 最終課題で考えてみると良いテーマでしょう <br> (脚注2) 商品が数十〜数百ならWeb APIサーバ全体をコピーしてよいと思います。 ちなみに、 アプリのなかに画像など(assets)をまるごと入れたシングルバイナリを作るやり方もあります。 例えば、Go言語なら go-bindata や go-assets を使って、そういうシングルバイナリを作ります。 コンテナなら、なおさら、このやり方がよいよね？ </small></small> </div>  <small> - Web APIサーバ = 本科目ではwww.pyのこと <br> (図中央のサーバ群に相当する) - ショッピングで見てまわるときは、コンテンツを見るだけ(READ ONLY)ですよね？ (図の1.) - 一式EC2の上にコンテンツとwww.pyを構築して、EC2をコピーすれば100台でも起動できます <br> (どのサーバに誘導するのか？は次回のテーマ) </small> --- class: compact,img-right # <small>キャッシュシステム(図の2.)</small> <div class=footnote> <small><small> (脚注1) www.pyやEC2が落ちたり再起動したときは、 ショッピングカートは一からやりなおしという作り方もありえます。 このへんは設計と運用の問題です。 でもショッピングカートをやり直させるのは、ビジネスチャンスを逃すことになるので、あまりやらないとは思いますけど ... (そういうサイトも実在はしますね) (脚注2) キーバリューストアやハッシュ、連想配列などシステムによって色々な呼び方がありますけど、 ようするに KEY => VALUE の組を扱うシステムです </small></small> </div>  <small> - `{商品 => 数量}`という値の組を保存できれば十分 - なぜなら、ショッピングカートなら、 顧客番号と商品と数量を保存しておけば、再現できますよね？ あと、購入前なら、最悪いちから商品を選び直してもらうのもありでしょう - 性能重視。やることが単純なのでキャッシュシステムは高速な動作が期待できます。 また、安定した性能が出せるように、古い情報は消してデータ量を抑制したりもします </small> --- class: compact,img-right # <small>RDBMS(リレーショナルデータベース管理システム,図の3.)</small> <div class=footnote> <small><small> (脚注1) 前ページで述べたように、 ある程度時間が経つとキャッシュは消えていく想定なので、 サイト会員のカートはRDBMSにも保存するとか、 キャッシュとRDBMSの使い分けが必要でしょう。 やはり、これも設計と運用の話になります (脚注2) RDSは選択肢が6種類あるのですが、もちろんAuroraが推奨です。 高価だけど高いだけの価値があります (注: AWS Academyでは利用できません) </small></small> </div>  <small> - キャッシュは性能重視で、あくまでも一時保存に使います - 購入履歴は、原則として消しません。そういったものはRDBMSに書きこみます - 何も考えずにRDBMSを構築すると、たんにサーバを一台つくって終わりになりますが、 これでは障害時にデータが失われます。 きちんと冗長構成のRDBMSを構築する必要がありますが、 けっこう面倒な構築なので、AWSなら素直にAWS RDSを購入しろ！という話になります </small>