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

1f745ff900e1be51aedae18cae76593c?s=47 Kurochan
September 25, 2019

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

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

1f745ff900e1be51aedae18cae76593c?s=128

Kurochan

September 25, 2019
Tweet

Transcript

  1. 2.

    黒崎 優太 • AI事業本部 • 広告配信事業の開発責任者 • 業務は Scala +

    AWS • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan
  2. 6.

    開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 • ⼊札トラフィック: 約8Gbps •

    レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
  3. 22.

    クラウドとは? • 巨⼤なサーバ/ストレージ/ネットワークといったリソースの集合の中で様々なサービス が提供されている環境のこと • 「マルチテナント」であることがポイント • 特定ユーザのために物理的なリソースを専有せず、共有するため利⽤効率がよくできる • 極端な例だとユーザは平均5%のCPUしか使わないのであれば、物理10CPUに対してVMで100CPUくらい


    割り当てても単純計算上は問題がないので、その分安く提供できる or 儲かる 
 (Amazon EC だとT系インスタンス以外はオーバーコミットしていない) • ⾼度に抽象化されているため、雲に例えられる • ⾼度に抽象化されているため、どのサーバで稼働しているのかといった配置よりも、
 サービスの組み合わせやサービス間の接続に注⽬した構成図で会話がされることが多い
  4. 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
  5. 46.

    リスクを認識する/許容する • 障害が起きないに越したことはないが、過剰にコストはかけられない • サービスの障害によって起きうる損失, 失う信⽤と、それを防ぐために
 かけるコストとバランスを考えどこまで求めるのかを選択する • ⼀定以上の⾼可⽤性に挑戦すると基本的には技術的難易度やコストは増加するはず •

    正しくリスクを認識することがただしいリスクの許容につながる • ⼀般的に起こりうる/想定される多くの事象は各種ミドルウェアなりクラウド サービスのドキュメントに書かれていることが多い • ドキュメントを読もう!!
  6. 49.

    実験をしてみる • マネージドサービスの障害時の挙動や、負荷を与えた時の挙動を確認する • 例: MySQL • MySQLのmaster 台 +

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

    真似をしてみる • マネージドサービスが⾃動で⾏ってくれるようなことを⾃前でやってみる • 例: MySQL • MySQLのmaster 台 +

    slave 台の構成を作る • masterを意図的にアクセス不能にする(シャットダウン or 通信断) • masterに通信できなくなったことを確認する • slaveのうち1台を選ぶ • 選んだslave 台をmasterに昇格させる
  8. 51.

    ⾃宅サーバをはじめる • とはいえクラウド(商⽤環境)はなかなか壊れないので、適当に作ってもある程度 は動いてしまいます • ⾃宅は簡単に障害が起こり得る / 障害が起きても被害(迷惑)が限定的です • トラブルシュートの練習にもなる

    • 何も⽤意されていないのでクラウドだと当たり前にある機能の存在に気づくことができます • 障害の例 • 実家のサーバで思い⽴って突然1200コンテナ起動したところ、IPアドレスの割当レンジを使い果 たして家族のIPアドレスがなくなり、「インターネットにつながらなくなった」と怒られる • サーバのNICが通信中だけ発熱して⼀定量通信すると応答がなくなり、しばらくすると復活する • ルータの冗⻑化(VRRP)に挑戦したが、ある⽇突然両⽅スタンバイになり通信途絶
  9. 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