「なんとなく」使うクラウドから「ちゃんと」使うクラウドへの入門 #awswakaran_tokyo

by Kurochan

Slide 1

Slide 1 text

「なんとなく」使うクラウドから  「ちゃんと」使うクラウドへの⼊⾨ #awswakaran_tokyo 株式会社サイバーエージェント AI事業本部  黒崎優太 (@kuro_m )

Slide 2

Slide 2 text

黒崎優太 • AI事業本部 • 広告配信事業の開発責任者 • 業務は Scala + AWS • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan

Slide 3

Slide 3 text

本⽇お話すること • AWSのAZ障害時の記事がきっかけで呼んで頂きました • この記事に関連して、アプリケーションエンジニアは何を気にすればいいのか、どんなことを知っていればいいのか？  クラウドインフラを使ってサービスを本番運⽤するにあたっての基礎的なお話をします。 • 新卒⼊社した4年半前まではほぼ触ったことがなかったので「わからん」状態から学んだことを話します。 • 業務でAWSをメインで使っているのでAWSでの例が多いです。

Slide 4

Slide 4 text

Contents • (普段業務で開発しているものの紹介) • クラウドとは？ • 「ちゃんと」使うには？ • 興味がある⼈向け情報

Slide 5

Slide 5 text

開発しているシステム • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •⽇本、アメリカを中⼼に数カ国に配信 •ユーザごとに最適化した広告を配信 http://www.dynalyst.io

Slide 6

Slide 6 text

開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 • ⼊札トラフィック: 約8Gbps • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD

Slide 7

Slide 7 text

クラウドっぽいことをしています • オートスケーリング系のメトリクス

Slide 8

Slide 8 text

もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/

Slide 9

Slide 9 text

クラウドとは？

Slide 10

Slide 10 text

よくあるクラウド • クラウドは概念図で現されがち • サービス構成としてはわかりやすいが、実際はどうなっているのか…？ https://d .awsstatic.com/architecture-diagrams/ArchitectureDiagrams/aws-industrial-PdM-ML-storage-RA.pdf

Slide 11

Slide 11 text

実際のクラウド • AWSを例に、かなりざっくり説明します • 厳密には正しくない/情報が⾜りていない部分もあるので、  雰囲気の理解にとどめてください • これを知っておくと⾊々な場⾯で役⽴つと思います

Slide 12

Slide 12 text

実際のクラウド • データセンタにサーバを並べますインターネット

Slide 13

Slide 13 text

実際のクラウド • サーバ上には各種サービスがデプロイされます • 1つの物理ホスト上で様々なユーザ向けのサービスが実⾏されます • サーバごとにユーザを分けるのではなく、サーバ上の各種リソース単位でユーザを区別しますインターネット

Slide 14

Slide 14 text

実際のクラウド • サーバを増やしたり、  データセンタを増やしたりしますインターネット

Slide 15

Slide 15 text

実際のクラウド • これがAZ(アベイラビリティーゾーン)です • AZは物理的、ソフトウェア的に⾃⽴している複数のデータセンタの集合の単位です • AZ内はレイテンシが0.25ms未満かつ帯域も⼗分に太いですインターネットアベイラビリティーゾーン

Slide 16

Slide 16 text

実際のクラウド • AZを複数個構成します • それぞれはレイテンシ的に問題がない距離に設置しますインターネットアベイラビリティーゾーン

Slide 17

Slide 17 text

実際のクラウド • AZ間の通信ができるようにそれぞれを  接続します(インターネットには出られない) インターネットアベイラビリティーゾーン

Slide 18

Slide 18 text

実際のクラウド • インターネットとアベイラビリティーゾーンの  接続点がトランジットセンターですインターネットトランジットセンターアベイラビリティーゾーン

Slide 19

Slide 19 text

実際のクラウド • トランジットセンターと  アベイラビリティーゾーンをつなぎますインターネットトランジットセンターアベイラビリティーゾーン

Slide 20

Slide 20 text

実際のクラウド • この集まりがリージョンですインターネットトランジットセンターアベイラビリティーゾーン

Slide 21

Slide 21 text

実際のクラウド • リージョンという単位でクラウドを各地(世界中)に構築すると、マルチリージョンになります

Slide 22

Slide 22 text

クラウドとは？ • 巨⼤なサーバ/ストレージ/ネットワークといったリソースの集合の中で様々なサービスが提供されている環境のこと • 「マルチテナント」であることがポイント • 特定ユーザのために物理的なリソースを専有せず、共有するため利⽤効率がよくできる • 極端な例だとユーザは平均5%のCPUしか使わないのであれば、物理10CPUに対してVMで100CPUくらい  割り当てても単純計算上は問題がないので、その分安く提供できる or 儲かる   (Amazon EC だとT系インスタンス以外はオーバーコミットしていない) • ⾼度に抽象化されているため、雲に例えられる • ⾼度に抽象化されているため、どのサーバで稼働しているのかといった配置よりも、  サービスの組み合わせやサービス間の接続に注⽬した構成図で会話がされることが多い

Slide 23

Slide 23 text

これを知っておくといいこと • 多くのサービスを利⽤するにあたって冗⻑性の⾯で何を気にすればいいのかがわかります

Slide 24

Slide 24 text

• AZ Aでアプリケーションを  稼働させていましたインターネットトランジットセンター AZ A 例: AZ障害 AZ B AZ C

Slide 25

Slide 25 text

• AZ Aが障害でダウンしました • サービスもダウンしましたインターネットトランジットセンター AZ A 例: AZ障害 AZ B AZ C

Slide 26

Slide 26 text

• 複数AZ + ロードバランサーで  サービスを稼働させていたらインターネットトランジットセンター AZ A 例: AZ障害 AZ B AZ C

Slide 27

Slide 27 text

• 1つのAZが障害になっても  他が⽣きているので⼤丈夫インターネットトランジットセンター AZ A 例: AZ障害 AZ B AZ C

Slide 28

Slide 28 text

「ちゃんと」使うには？

Slide 29

Slide 29 text

「ちゃんと」使うには？ • 「わからん」から脱却するには？ • この構成/⼿法が絶対に正解というのはないが、少なくとも推奨されていないような構成を意図せず選んでしまうのは避けておきたい… • 基本的な事をおさえた上で技術的に攻めた構成にもチャレンジしてみたいはず

Slide 30

Slide 30 text

ドキュメントを読む！ https://docs.aws.amazon.com/ja_jp/AWSEC /latest/UserGuide/concepts.html

Slide 31

Slide 31 text

ドキュメントを読む！ • ドキュメントにだいたいのことは書かれています • 使うサービスは最低限⼀度は⽬を通すべき • 英語版の⽅がupdateは早かったり、情報が正確だったりするので細かい部分や最新の部分は英語版を読むのがおすすめ

Slide 32

Slide 32 text

仕組みが想像できるかどうか • パブリッククラウドは技術的な詳細は公開されていないが、おおまかな構成はドキュメントに書かれているし、明⽰されていなくても推測できる情報もある • さきほどのAZの例のように、仕組みが想像できれば、検討/設計/導⼊する上で気になる部分/気にするべき部分がおのずと明確になるはず

Slide 33

Slide 33 text

責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/

Slide 34

Slide 34 text

責任共有モデル • よく出てくる図 • 責任境界はサービスによって変わってくるが、全てにおいて共通しているのはユーザのアプリケーションをアプリケーションレイヤで維持するのはユーザの責任 • セキュリティ(「機密性」「可⽤性」「完全性」)の⽂脈においてのモデルだが、セキュリティではない切り⼝においても考え⽅として覚えておいたほうがよい

Slide 35

Slide 35 text

SLA！ • クラウド事業者と顧客との責任範囲の定義, 責任を果たせなかった場合の対応 • 例: Amazon EC • サービス利⽤者がインスタンスまたはタスク（コンテイナー1 個以上）のうち該当するものを実⾏している同⼀地域内の複数の Availability Zone が、サービス利⽤者にとって同時に「使⽤不能」となることをいう。 • ↑の定義の状態でない状態を⽉の99.99%以上維持するのがAWSのコミットメント • 下回れば⼀部返⾦(ユーザが請求する必要がある) • SLAがないサービスももちろん存在する • クラウド事業者は提供するサービスにのみ責任を持っている  その上にシステムを構築し価値を提供するのは我々であるため、⾃分たちで構築したレイヤの責任は⾃分たちで負わなければならない https://d .awsstatic.com/legal/amazon-ec -sla/Amazon_EC _Service_Level_Agreement_-_Japanese_Translation__ - - _.pdf

Slide 36

Slide 36 text

リスクを認識する/許容する • AZ構成のアプリケーションにおいて、1AZ単位の障害にほぼ確実に  耐えられるようにする構成を検討する

Slide 37

Slide 37 text

• 負荷分散 + 冗⻑化インターネットトランジットセンター AZ A 例: 複数AZ + ロードバランサー AZ B AZ C

Slide 38

Slide 38 text

• 1つのAZが障害になっても  他が⽣きているので⼤丈夫…？インターネットトランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー

Slide 39

Slide 39 text

• AZで100%のキャパシティだったので、  AZ失われた事により突然66%の  キャパシティにインターネットトランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー

Slide 40

Slide 40 text

• アプリケーションが負荷に耐えきれず結局サービスダウンインターネットトランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー

Slide 41

Slide 41 text

• オートスケールにより負荷に応じて  キャパシティを⾃動で調整するインターネットトランジットセンター AZ A 例:オートスケール AZ B AZ C

Slide 42

Slide 42 text

• AZ障害発⽣！ • オートスケールで他のAZでリソースをまかなう  (多くの場合うまくいくはず…) インターネットトランジットセンター AZ A 例:オートスケール AZ B AZ C

Slide 43

Slide 43 text

• 同じように急激な負荷に対応しようと  皆サーバを増強しはじめ、  AZ内のサーバの在庫が不⾜！新規起動失敗！インターネットトランジットセンター AZ A 例:オートスケール AZ B AZ C

Slide 44

Slide 44 text

ほぼ確実にキャパシティを担保するには • AZの構成において、1AZ単位での障害で100%のキャパシティを確実に維持できるようにするためには常に必要なキャパシティの150%のリソースを投⼊しておかなければならない • 単純に⽐較はできないが、⾃社データセンタで冗⻑化のために2倍のリソースを投⼊していた頃と⽐較してクラウドに移⾏したら安くなりましたという主張をしていたら危険 • もちろんコストは100%のキャパシティを維持する⽅式に⽐べ1.5倍になる • コストが全く問題ではない場合はこの選択肢を取るのが確実

Slide 45

Slide 45 text

リスクを認識する/許容する • 前述の⽅法だと必要なキャパシティに対して1.5倍のリソースが必要 • クライアントサイドでのリトライや、サービスの縮退機能によって⼀時的にサービスの提供レベルを下げられるとしたら…？ • AZ障害は頻繁に起きるものではないはずという仮定のもと、オートスケールによる復旧/インスタンスサイズを変更してのトライが成功するのを待つことが許容できるとしたら…？ • コストを下げることはできそう

Slide 46

Slide 46 text

リスクを認識する/許容する • 障害が起きないに越したことはないが、過剰にコストはかけられない • サービスの障害によって起きうる損失, 失う信⽤と、それを防ぐために  かけるコストとバランスを考えどこまで求めるのかを選択する • ⼀定以上の⾼可⽤性に挑戦すると基本的には技術的難易度やコストは増加するはず • 正しくリスクを認識することがただしいリスクの許容につながる • ⼀般的に起こりうる/想定される多くの事象は各種ミドルウェアなりクラウドサービスのドキュメントに書かれていることが多い • ドキュメントを読もう！！

Slide 47

Slide 47 text

興味がある⼈向け情報

Slide 48

Slide 48 text

どんな仕組みなのか調べてみる • AWSはre:Inventというイベントを毎年開催していてそこでサービスの裏側や設計思想について語るセッションがあったりする • 利⽤する上で知らなければならない情報ではないが、知っておくとかなり理解が深まる • Youtubeにほとんどの動画は公開されている • 好きな動画の例 • AWS re:Invent : Another Day, Another Billion Packets (NET ) • VPCの仕組みについて、マルチテナントなネットワークをどうやってスケールさせるのか https://www.youtube.com/watch?v=St SE LWhKo

Slide 49

Slide 49 text

実験をしてみる • マネージドサービスの障害時の挙動や、負荷を与えた時の挙動を確認する • 例: MySQL • MySQLのmaster 台 + slave 台の構成を作る • (障害発⽣の代わりに) masterを再起動させる • ⾃動的にslaveのうちから1台が選ばれ、masterに昇格していることを確認する • その時のログ等を確認する • ドキュメント通りの挙動をしているか、⾃分の理解と合っているか順を追って確かめる • フルマネージドなサービスに近づけば近づくほど実験をするのは難しい… • 例えばAWS LambdaやAmazon S の障害時の挙動を意図的に確かめることは不可能 • そもそもベストプラクティスに沿っていれば基盤側の障害に気づかないかもしれない

Slide 50

Slide 50 text

真似をしてみる • マネージドサービスが⾃動で⾏ってくれるようなことを⾃前でやってみる • 例: MySQL • MySQLのmaster 台 + slave 台の構成を作る • masterを意図的にアクセス不能にする(シャットダウン or 通信断) • masterに通信できなくなったことを確認する • slaveのうち1台を選ぶ • 選んだslave 台をmasterに昇格させる

Slide 51

Slide 51 text

⾃宅サーバをはじめる • とはいえクラウド(商⽤環境)はなかなか壊れないので、適当に作ってもある程度は動いてしまいます • ⾃宅は簡単に障害が起こり得る / 障害が起きても被害(迷惑)が限定的です • トラブルシュートの練習にもなる • 何も⽤意されていないのでクラウドだと当たり前にある機能の存在に気づくことができます • 障害の例 • 実家のサーバで思い⽴って突然1200コンテナ起動したところ、IPアドレスの割当レンジを使い果たして家族のIPアドレスがなくなり、「インターネットにつながらなくなった」と怒られる • サーバのNICが通信中だけ発熱して⼀定量通信すると応答がなくなり、しばらくすると復活する • ルータの冗⻑化(VRRP)に挑戦したが、ある⽇突然両⽅スタンバイになり通信途絶

Slide 52

Slide 52 text

おすすめ⾃宅サーバ • Intel NUC • Intelの⼿のひらサイズの⼩型PC • とても静かで省電⼒なので部屋で常時起動させておいても気になりません • Core i モデルでだいたいのことは試せます • メモリは16GB〜 GBくらい搭載できると⾊々遊べます • Nginx / MySQL / Redis / Linux Container / Docker / KVM / Kubernetes / ⾃作アプリ…   等々⾊々作っては壊しするのがおすすめです https://www.intel.co.jp/content/www/jp/ja/products/boards-kits/nuc.html

Slide 53

Slide 53 text

まとめ • クラウド環境でシステムを構築するにあたって知っておくべき前提知識や考え⽅について紹介しました。 • わかりやすいのでAZ障害を例にしましたが、その他に関しても考え⽅的には応⽤できるはずです。 • 「イラスト図解でよくわかる ITインフラ基礎知識」もおすすめです！！(宣伝) • 表紙は普通っぽいですが、ISPやデータセンタの話や障害対応について載っていたりします。 http://gihyo.jp/book/ / - - - -