TT Lab
はじめる
学ぶ 学習パス コース

クラウドの基本

クラウドの決定を数字で行う

TT Labで続きを見る

目標

クラウドを概念でしか学ばないと、決めるときに使えません。このラボは、決定に必要なものを数字で求めます。

開始

cp -r /opt/lab/cloudbasics/* .
python3 latency.py 11000 --real 180
python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

ファイル

ファイル 役割
latency.py 距離 → 最小往復時間
tco.py 人の時間を入れたコスト比較
incidents.txt 事故10個。ここを埋めます

ステップ

  1. 物理的な限界 → 01-physics.txt
  2. リージョンの選択 → 02-region.md
  3. AZとリージョン → 03-az.md
  4. 責任共有 → incidents.txt
  5. TCO → 05-tco.txt
  6. 損益分岐 → 06-breakeven.md
  7. クラウドが答えではないとき → 07-notcloud.md
  8. まとめ → 08-notes.md

参考

距離と料金は概算です。重要なのは桁数です。1msと100msは、同じ種類の数ではありません。

お金で減らせないもの

ソウル↔バージニア(約11,000km)の最小往復時間を求めて、01-physics.txtに残してください。実際の測定値は約180msです。差も一緒に書きます。

python3 latency.py 11000 --real 180

光は真空中では300,000km/sですが、光ファイバーの中では約200,000km/sです(屈折率1.5)。

110msは物理的な限界です。インスタンスを大きくしたり、お金を多く払ったりしても減らせません。クラウドで唯一の「買えないもの」であり、そのため、アーキテクチャで解く必要があります。

では、リージョンをどこに置くか

ユーザーの大半が韓国にいるサービスのリージョンをどこに置くか、02-region.mdに書き、数字で根拠を示してください。

ステップ1の数字を使ってください。ソウルリージョンならユーザーまで何ms、バージニアなら何msですか。

そして、往復が何回起きるかを考えてみてください。1ページでAPIを5回呼び出すと、往復も5回です。110ms × 5 = 550msで、これは何もしていない時間です。

AZはなぜ分かれているのか

AZ間のレイテンシとリージョン間のレイテンシの桁数を比較して03-az.mdに書き、なぜAZを分けて使うのかを説明してください。

AZは同じ都市圏の別の建物です。距離が数十kmなので、往復は1ms前後です。リージョン間は数十–数百msです。

同じ値段で違うものを買います。AZを分ければ、建物が1つ落ちても生き残るのに、レイテンシはほとんど増えません。リージョンを分ければ、都市が落ちても生き残りますが、レイテンシが100倍になります。

誰が何を守るのか

incidents.txtの10個の事故それぞれに、cloudまたはmeを書いて埋めてください。形式は번호|사고|답です(プレースホルダーは番号、事故、答えです)。

判断基準は1つ。自分が設定できるものは自分の責任です。

バケットの公開設定も、IAMキーの管理も、OSのアップデートも、自分で行います。ハイパーバイザーのパッチと物理的な入退室管理は、自分では手を出せないので、事業者の責任です。

紛らわしいものが2つあります。AZの電源障害は事業者の責任ですが、そこにだけデプロイしていたことは自分の責任です。マネージドDBのマイナーパッチは、事業者が行います。

マネージドは高いのか

自前運用とマネージドの1か月のコストを、人の時間を入れて比較し、05-tco.txtに残してください。

python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

インフラ料金だけを見ると、マネージドが2倍以上高く見えます。人の時間20時間を入れると、マネージドが月700$安くなります。

人の時間は帳簿に載らないため、何度も0として扱われます。そして、その時間はたいてい夜に、事故が起きたときにかかります。

損益分岐を求める

自前運用のほうが安くなるには、月に何時間未満である必要があるかを求め、それが現実的かどうかを06-breakeven.mdに書いてください。

tco.pyが損益分岐を教えてくれます。上の条件なら8.3時間です。

月に8時間で、バックアップの確認、パッチ、モニタリング、容量の点検、そして1回の障害対応までできるでしょうか。現実的ですか。

そして、その時間を使う人がほかの仕事をできなくなるというコストもあります(機会コスト)。帳簿には出てきません。

クラウドが答えではないとき

クラウドのほうがより高い、または不適切な場合を2つ以上見つけて、07-notcloud.mdに書いてください。それぞれ、理由も一緒に書きます。

考えてみる点は次のとおりです。負荷が一定で予測でき、3年以上使う大量のコンピュート、データを大量に持ち出す必要があるワークロード(エグレス料金)、データの所在地規制、特殊なハードウェアです。

「クラウドは安い」ではなく、クラウドは柔軟なのです。柔軟性が必要なければ、その代金を払う理由もありません。

まとめる

08-notes.mdに3行以上書いてください。お金では買えないもの、責任共有の判断基準、マネージドのコストを見るときに見落としやすいものです。

本文に지연・설정・사람が含まれている必要があります(韓国語で、順に「レイテンシ」「設定」「人」を意味する語です)。