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

awswakaran.​tokyo #2での発表資料です

Transcript

1. 「なんとなく」使うクラウドから
 「ちゃんと」使うクラウドへの⼊⾨ #awswakaran_tokyo 株式会社サイバーエージェント AI事業本部
 黒崎 優太 (@kuro_m )
2. 黒崎 優太 • AI事業本部 • 広告配信事業の開発責任者 • 業務は Scala + AWS • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan
3. 本⽇お話すること • AWSのAZ障害時の記事がきっかけで呼んで頂きました • この記事に関連して、アプリケーションエンジニアは何を気にすればいいのか、どんなことを知っていればいいのか？
 クラウドインフラを使ってサービスを本番運⽤するにあたっての基礎的なお話をします。 • 新卒⼊社した4年半前まではほぼ触ったことがなかったので「わからん」状態から学んだことを話します。 • 業務でAWSをメインで使っているのでAWSでの例が多いです。
4. Contents • (普段業務で開発しているものの紹介) • クラウドとは？ • 「ちゃんと」使うには？ • 興味がある⼈向け情報
5. 開発しているシステム • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •⽇本、アメリカを中⼼に数カ国に配信 •ユーザごとに最適化した広告を配信 http://www.dynalyst.io
6. 開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 • ⼊札トラフィック: 約8Gbps • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
7. クラウドっぽいことをしています • オートスケーリング系のメトリクス
8. もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/
9. クラウドとは？
10. よくあるクラウド • クラウドは概念図で現されがち • サービス構成としてはわかりやすいが、実際はどうなっているのか…？ https://d .awsstatic.com/architecture-diagrams/ArchitectureDiagrams/aws-industrial-PdM-ML-storage-RA.pdf
11. 実際のクラウド • AWSを例に、かなりざっくり説明します • 厳密には正しくない/情報が⾜りていない部分もあるので、
 雰囲気の理解にとどめてください • これを知っておくと⾊々な場⾯で役⽴つと思います
12. 実際のクラウド • データセンタにサーバを並べます インターネット
13. 実際のクラウド • サーバ上には各種サービスがデプロイされます • 1つの物理ホスト上で様々なユーザ向けのサービスが実⾏されます • サーバごとにユーザを分けるのではなく、サーバ上の各種リソース単位でユーザを区別します インターネット
14. 実際のクラウド • サーバを増やしたり、
 データセンタを増やしたりします インターネット
15. 実際のクラウド • これがAZ(アベイラビリティーゾーン)です • AZは物理的、ソフトウェア的に⾃⽴している複数のデータセンタの集合の単位です • AZ内はレイテンシが0.25ms未満かつ帯域も⼗分に太いです インターネット アベイラビリティーゾーン
16. 実際のクラウド • AZを複数個構成します • それぞれはレイテンシ的に問題がない距離に設置します インターネット アベイラビリティーゾーン
17. 実際のクラウド • AZ間の通信ができるようにそれぞれを
 接続します(インターネットには出られない) インターネット アベイラビリティーゾーン
18. 実際のクラウド • インターネットとアベイラビリティーゾーンの
 接続点がトランジットセンターです インターネット トランジットセンター アベイラビリティーゾーン
19. 実際のクラウド • トランジットセンターと
 アベイラビリティーゾーンをつなぎます インターネット トランジットセンター アベイラビリティーゾーン
20. 実際のクラウド • この集まりがリージョンです インターネット トランジットセンター アベイラビリティーゾーン
21. 実際のクラウド • リージョンという単位でクラウドを各地(世界中)に構築すると、マルチリージョンになります
22. クラウドとは？ • 巨⼤なサーバ/ストレージ/ネットワークといったリソースの集合の中で様々なサービス が提供されている環境のこと • 「マルチテナント」であることがポイント • 特定ユーザのために物理的なリソースを専有せず、共有するため利⽤効率がよくできる • 極端な例だとユーザは平均5%のCPUしか使わないのであれば、物理10CPUに対してVMで100CPUくらい
 割り当てても単純計算上は問題がないので、その分安く提供できる or 儲かる 
 (Amazon EC だとT系インスタンス以外はオーバーコミットしていない) • ⾼度に抽象化されているため、雲に例えられる • ⾼度に抽象化されているため、どのサーバで稼働しているのかといった配置よりも、
 サービスの組み合わせやサービス間の接続に注⽬した構成図で会話がされることが多い
23. これを知っておくといいこと • 多くのサービスを利⽤するにあたって冗⻑性の⾯で何を気にすればいいのかが わかります
24. • AZ Aでアプリケーションを
 稼働させていました インターネット トランジットセンター AZ A 例: AZ障害 AZ B AZ C
25. • AZ Aが障害でダウンしました • サービスもダウンしました インターネット トランジットセンター AZ A 例: AZ障害 AZ B AZ C
26. • 複数AZ + ロードバランサーで
 サービスを稼働させていたら インターネット トランジットセンター AZ A 例: AZ障害 AZ B AZ C
27. • 1つのAZが障害になっても
 他が⽣きているので⼤丈夫 インターネット トランジットセンター AZ A 例: AZ障害 AZ B AZ C
28. 「ちゃんと」使うには？
29. 「ちゃんと」使うには？ • 「わからん」から脱却するには？ • この構成/⼿法が絶対に正解というのはないが、少なくとも推奨されていないよ うな構成を意図せず選んでしまうのは避けておきたい… • 基本的な事をおさえた上で技術的に攻めた構成にもチャレンジしてみたいはず
30. ドキュメントを読む！ https://docs.aws.amazon.com/ja_jp/AWSEC /latest/UserGuide/concepts.html
31. ドキュメントを読む！ • ドキュメントにだいたいのことは書かれています • 使うサービスは最低限⼀度は⽬を通すべき • 英語版の⽅がupdateは早かったり、情報が正確だったりするので細かい部分や 最新の部分は英語版を読むのがおすすめ
32. 仕組みが想像できるかどうか • パブリッククラウドは技術的な詳細は公開されていないが、おおまかな構成は ドキュメントに書かれているし、明⽰されていなくても推測できる情報もある • さきほどのAZの例のように、仕組みが想像できれば、検討/設計/導⼊する上で 気になる部分/気にするべき部分がおのずと明確になるはず
33. 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/
34. 責任共有モデル • よく出てくる図 • 責任境界はサービスによって変わってくるが、全てにおいて共通しているのは ユーザのアプリケーションをアプリケーションレイヤで維持するのはユーザの 責任 • セキュリティ(「機密性」「可⽤性」「完全性」)の⽂脈においてのモデルだ が、セキュリティではない切り⼝においても考え⽅として覚えておいたほうが よい
35. 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
36. リスクを認識する/許容する • AZ構成のアプリケーションにおいて、1AZ単位の障害にほぼ確実に
 耐えられるようにする構成を検討する
37. • 負荷分散 + 冗⻑化 インターネット トランジットセンター AZ A 例: 複数AZ + ロードバランサー AZ B AZ C
38. • 1つのAZが障害になっても
 他が⽣きているので⼤丈夫…？ インターネット トランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー
39. • AZで100%のキャパシティだったので、
 AZ失われた事により突然66%の
 キャパシティに インターネット トランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー
40. • アプリケーションが負荷に耐えき れず結局サービスダウン インターネット トランジットセンター AZ A AZ B AZ C 例: 複数AZ + ロードバランサー
41. • オートスケールにより負荷に応じて
 キャパシティを⾃動で調整する インターネット トランジットセンター AZ A 例:オートスケール AZ B AZ C
42. • AZ障害発⽣！ • オートスケールで他のAZでリソースをまかなう
 (多くの場合うまくいくはず…) インターネット トランジットセンター AZ A 例:オートスケール AZ B AZ C
43. • 同じように急激な負荷に対応しようと
 皆サーバを増強しはじめ、
 AZ内のサーバの在庫が不⾜！新規起動失敗！ インターネット トランジットセンター AZ A 例:オートスケール AZ B AZ C
44. ほぼ確実にキャパシティを担保するには • AZの構成において、1AZ単位での障害で100%のキャパシティを確実に維持で きるようにするためには常に必要なキャパシティの150%のリソースを投⼊し ておかなければならない • 単純に⽐較はできないが、⾃社データセンタで冗⻑化のために2倍のリソースを投⼊していた頃 と⽐較してクラウドに移⾏したら安くなりましたという主張をしていたら危険 • もちろんコストは100%のキャパシティを維持する⽅式に⽐べ1.5倍になる • コストが全く問題ではない場合はこの選択肢を取るのが確実
45. リスクを認識する/許容する • 前述の⽅法だと必要なキャパシティに対して1.5倍のリソースが必要 • クライアントサイドでのリトライや、サービスの縮退機能によって⼀時的に サービスの提供レベルを下げられるとしたら…？ • AZ障害は頻繁に起きるものではないはずという仮定のもと、オートスケールに よる復旧/インスタンスサイズを変更してのトライが成功するのを待つことが許 容できるとしたら…？ • コストを下げることはできそう
46. リスクを認識する/許容する • 障害が起きないに越したことはないが、過剰にコストはかけられない • サービスの障害によって起きうる損失, 失う信⽤と、それを防ぐために
 かけるコストとバランスを考えどこまで求めるのかを選択する • ⼀定以上の⾼可⽤性に挑戦すると基本的には技術的難易度やコストは増加するはず • 正しくリスクを認識することがただしいリスクの許容につながる • ⼀般的に起こりうる/想定される多くの事象は各種ミドルウェアなりクラウド サービスのドキュメントに書かれていることが多い • ドキュメントを読もう！！
47. 興味がある⼈向け情報
48. どんな仕組みなのか調べてみる • AWSはre:Inventというイベントを毎年開催していてそこでサービスの裏側や 設計思想について語るセッションがあったりする • 利⽤する上で知らなければならない情報ではないが、知っておくとかなり理解が深まる • Youtubeにほとんどの動画は公開されている • 好きな動画の例 • AWS re:Invent : Another Day, Another Billion Packets (NET ) • VPCの仕組みについて、マルチテナントなネットワークをどうやってスケールさせるのか https://www.youtube.com/watch?v=St SE LWhKo
49. 実験をしてみる • マネージドサービスの障害時の挙動や、負荷を与えた時の挙動を確認する • 例: MySQL • MySQLのmaster 台 + slave 台の構成を作る • (障害発⽣の代わりに) masterを再起動させる • ⾃動的にslaveのうちから1台が選ばれ、masterに昇格していることを確認する • その時のログ等を確認する • ドキュメント通りの挙動をしているか、⾃分の理解と合っているか順を追って確かめる • フルマネージドなサービスに近づけば近づくほど実験をするのは難しい… • 例えばAWS LambdaやAmazon S の障害時の挙動を意図的に確かめることは不可能 • そもそもベストプラクティスに沿っていれば基盤側の障害に気づかないかもしれない
50. 真似をしてみる • マネージドサービスが⾃動で⾏ってくれるようなことを⾃前でやってみる • 例: MySQL • MySQLのmaster 台 + slave 台の構成を作る • masterを意図的にアクセス不能にする(シャットダウン or 通信断) • masterに通信できなくなったことを確認する • slaveのうち1台を選ぶ • 選んだslave 台をmasterに昇格させる
51. ⾃宅サーバをはじめる • とはいえクラウド(商⽤環境)はなかなか壊れないので、適当に作ってもある程度 は動いてしまいます • ⾃宅は簡単に障害が起こり得る / 障害が起きても被害(迷惑)が限定的です • トラブルシュートの練習にもなる • 何も⽤意されていないのでクラウドだと当たり前にある機能の存在に気づくことができます • 障害の例 • 実家のサーバで思い⽴って突然1200コンテナ起動したところ、IPアドレスの割当レンジを使い果 たして家族のIPアドレスがなくなり、「インターネットにつながらなくなった」と怒られる • サーバのNICが通信中だけ発熱して⼀定量通信すると応答がなくなり、しばらくすると復活する • ルータの冗⻑化(VRRP)に挑戦したが、ある⽇突然両⽅スタンバイになり通信途絶
52. おすすめ⾃宅サーバ • 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
53. まとめ • クラウド環境でシステムを構築するにあたって知っておくべき前提知識や考え⽅ について紹介しました。 • わかりやすいのでAZ障害を例にしましたが、その他に関しても考え⽅的には応⽤ できるはずです。 • 「イラスト図解でよくわかる ITインフラ基礎知識」もおすすめです！！(宣伝) • 表紙は普通っぽいですが、ISPやデータセンタの話や障害対応について載っていたりします。 http://gihyo.jp/book/ / - - - -