name: overview class: title, smokescreen, shelf, no-footer # クラウドらしい設計 <div class=footnote> <small> (脚注) </small> </div> --- class: compact # 現代のシステム設計の羊蹄 <div class=footnote> <small> <small> </small> </small> </div> 1. システム障害は必ず起こる、回避できない 1. システム障害が起こる前提で設計・構築・運用せよ 1. お客様が障害に気づかずサービスを使いつづけられればOK --- class: compact # システム障害とは <div class=footnote> <small> <small> こういった場合にも、お客様に気づかれることなく、サービスを継続してください </small> </small> </div> 本科目が想定しているモダンな「システムの障害」とは何か? - サーバが落ちるような類のエラー - (いまどき仮想なので) <br> なんらかのソフトウエア障害でサーバ(仮想マシン)が停止・再起動 - ハードウエア障害 - サーバ(PC)がハードウエア障害で停止・再起動 - データセンターの通信回線の障害、電源障害、空調障害 - 想定を越えてサービスがブレイクした場合 - 例: ソーシャルゲーム(1万人くらいかな?と思ったら100万人きた) - 逆に、ブレイクしなかった場合、お客様に気づかずに余分なサーバ数を停止 --- class: compact # システム障害への対策 <div class=footnote> <small> <small> (脚注) AZとリージョンは重要なAWS用語(復習)なので、きちんと違いを説明できるようにしておくこと <br> BCP = Business Continuity Plan (事業継続計画); 緊急時に事業継続するための計画のこと(経営用語) </small> </small> </div> - 冗長化構成 - AWSの場合の模範解答 - <B>複数のAZに分散されたシステム</B>で構築されている(当然やるべきレベル) - BCP(災害対策)として別リージョンにバックアップシステムの準備あり <br> (理想,予算しだい) - スケールアウト/イン(scale out/scale in) - 自社固有のアプリケーションもスケール出来るように作りこみます <br> (<B>ステートレス</B>が基本) --- class: compact # AWSでの運用の基本はサービスを買え <div class=footnote> <small> <small> (脚注1) もちろんオンプレミスでも札束で人を雇えば同じことだが、 クラウドのスケールメリットには、とうてい勝てない <br> (脚注2) デメリットは自社やエンジニア自身の技術力は上がらないしノウハウも蓄積されない </small> </small> </div> - <B>AWSが面倒を見てくれるサービス(managed service)は素直に買え</B> - 代表例がAWS RDSの<B>Aurora</B> - RDBMSの面倒なんて見たくないよ by インフラチーム - 理由 <small> - AWSのいいところは「<B>札束でメンテナンスを買える</B>」こと - ソフトウエアのアップグレード - セキュリティ対策 - 障害対応 - ユーザ数が膨大なメリット - ユーザ数が多ければバグ報告なども多く、必然的にノウハウが集まる -> サービスの改善 - メンテナンスの準備は少人数でできるが、それをユーザ数で割るので1件あたりのコストは激安 (オンプレミスの場合、そのコストを全て請求されうるわけだから、大きな違い) </small> --- name: appendix class: title, smokescreen, shelf, no-footer # 付録 <div class=footnote> <small> </small> </div> --- class: compact # 古典的な回答: ロックファイル方式 (クラウドではダメ) <div class=footnote> <small> <small> (脚注1) この授業では解説しませんが、 OSの教科書で該当する用語は、このあたり: セマフォ, mutex, CV, モニタ <br> (脚注2) 処理の少ないサーバなら、 こういう古典方式でも大丈夫でしょうけど、 クラウドを使う商用サービスではダメということ </small> </small> </div> <small> ``` [擬似コード] ロックファイルを作製(すでに存在するなら、それを使う) ロックファイルに対してロックをかける if (ロックに成功したら) { 何らかの処理をする 例: ショッピングサイトの購入処理 ロックを外す } else { ロックをとれなかった場合 // ここは書き方の選択肢あり 1. ロックとれるまで無限に待つ 2. ロックとれるか?10秒だけ待ち続ける 3. ロックとれたら呼んでもらうことにして通過 } ``` </small> --- class: compact # [参考] SQLのトランザクション <div class=footnote> <small> <small> (脚注) 実際の SQL サーバの中の動作は、少し違うと思うけど、 各命令文の論理的な意味は、こんなかんじ </small> </small> </div> ``` // 一続きの処理を始める、つまりC言語の { みたいなもの BEGIN; INSERT INTO 購入 (商品,数量) VALUES (A, 1) ... その他のSQL命令、たとえばショッピングカートの商品を削除ほか // (命令文はないけど、} があると考える) // { ... } の処理を行う(ロックして、実際に書きこむ) COMMIT; // (命令文は無いけど)ロックをはずして終わり ```