Go to Qiita Advent Calendar Top
LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@orangist

【検討】なんでもクラウドじゃない！“合わなかった”要件を考えてみる

Posted at

なんでもクラウドじゃない！“合わなかった”要件を考えてみる

対象読者

  • システムでクラウド採否を判断する人
  • 「クラウドで失敗しがちな条件」と「クラウド外／ハイブリッドの方が良いシグナル」を押さえたい人

TL;DR

  • データ重力（容量×転送）・定常負荷・ログ取り過ぎ・レイテンシ分断があるとクラウドは不利に傾きやすい。
  • ベンダー別の“費目の地雷”は違う：AWS=転送/NAT、GC=Cloud NAT/Logging 取り込み、Azure=Log Analytics/NAT GW＋帯域。
  • 公開事例（Dropbox/37signals/NTTぷらら等）から「いつ戻す/混ぜるか」の判断軸を持とう。

1. まず“クラウド不利”になりやすい要件・ケース

  • 恒常的なVPC外の通信（特に社内DC/拠点向け配信）やクロスAZ転送が大きい

    「同一リージョン内AZ間の転送は 課金対象…リソースによっては送受ともに課金」 (AWS ドキュメント)
    「NAT Gateway は 時間＋処理GB を課金」 (AWS ドキュメント)

  • 8割が定常負荷でスパイクが小さい（予約割引を目一杯使ってもオンプレTCOが勝つことがある）

  • 巨大で疎アクセスな保管（PB級）：長期の保管＋取り出し＋転送でTCO逆転の余地（※コールドストレージとかを使わない場合）

  • 観測データの取り過ぎ（ログ/メトリクス/トレース）

    「Cloud Logging の請求はログバケットに取り込まれたログのみ」 (Google Cloud)
    「Azure Monitor は取り込みと保持が主料金」 (マイクロソフトラーニング)

  • レイテンシ分断（DBがオンプレ/アプリはクラウド等）：往復遅延で失速しやすい

2. 公開されている“失敗”事例

Dropbox：AWS → 自社ストレージ（Magic Pocket）

  • 2016〜2018 頃に大半を自社へ。目的は経済性と最適化。

    “moved about 90% of its operation off of the Amazon cloud” (WIRED)
    公式ストーリー「Magic Pocket」：自社最適化の背景。 (WIRED)
    日本記事まとめも。 (ASCII)

37signals（Basecamp/HEY）：AWS/GC → 自社ハード

  • 年間 $3.2M → $1.3M まで削減、公表済み。

    “reduced its cloud bill from $3.2M/yr to $1.3M” (Datacenter Dynamics)
    “$10M/5年 のセービング”（公式ランディング） (Basecamp)
    原典（DHH）も。 (world.hey.com)

NTTぷらら「ひかりTV」：Azure Blob → オンプレECS

  • 22億ファイル移行。理由はコストと運用。 (IT Leaders)

まとめ：定常×大容量×恒常egressの組み合わせはクラウド不利に振れやすい（事例一致）。

3. 主要クラウド別 “合わなかった”典型と対処

AWS（転送,NAT,クロスAZが効きやすい）

  • NAT Gateway の多重課金（時間＋GB）

    “charged for each hour … and each gigabyte of data that it processes.” (AWS ドキュメント)
    対処：PrivateLink/VPCエンドポイント/S3 GW で NAT 経由を極力ゼロへ。PrivateLinkの時間＋GB課金も忘れず見積り。 (Amazon Web Services, Inc.)

  • LB経由の転送/クロスAZ積み上げ：公式ブログでパターン別に費目整理あり。 (Amazon Web Services, Inc.)

  • 広域障害の影響半径（最近の us-east-1）

    “root cause was DNS issues affecting DynamoDB… US-EAST-1” (The Verge)
    対処：マルチリージョン化＋依存SaaS（IDP/DNS等）も二経路に。

Google Cloud（Cloud NAT/Logging/単リージョン過信）

  • Cloud NAT は「ゲートウェイ時間＋処理GB＋外部IP時間」＋別途 egress

    “hourly for the gateway… $0.045/GB processed… data transfer costs also apply.” (Google Cloud)

  • Cloud Logging は“取り込み量×保持”がコスト源

    “請求は…ログバケットに取り込まれたログに対してのみ発生” (Google Cloud)

  • Paris（europe-west9）水害→火災由来インシデント（2023/04）
    公式ステータスと報道で確認。 (status.cloud.google.com)
    対処：DR前提（ゾーン/リージョン二重化）＋Private Service ConnectでAPIを私設経路へ。 (Google Cloud Documentation)

Azure（Log Analytics/NAT GW＋帯域/DNS複雑性）

  • Log Analytics：主料金は取り込みと保持

    「最も重要な料金は取り込みと保持」 (マイクロソフトラーニング)

  • NAT Gateway：データ処理＋帯域が別建て

    「NAT の処理料金に加えて帯域幅料金も適用」 (Microsoft Azure)

  • Private Endpoint の DNS 設計が複雑（解決失敗の温床）
    ドキュメントでパターンと Private Resolver の指針。 (マイクロソフトラーニング)

  • South Central US（2018）：落雷→冷却喪失→長時間復旧。広域依存（AD/DevOps等）で波及。 (GeekWire)

4. 代表的“費目の地雷”

  • AWS：NAT/LB/クロスAZ/インターネット転送

    「NATは時間＋処理GBで課金」 (AWS ドキュメント)
    「NLBの転送コストは構成により変動（公式解説）」 (Amazon Web Services, Inc.)
    「AZ間転送は課金」 (AWS ドキュメント)

  • GC：Cloud NAT + egress／Logging 取り込み

    「Cloud NAT はゲートウェイ時間＋1GiBあたり＋外部IP時間＋データ転送コスト適用」 (Google Cloud)
    「Cloud Logging は取り込みのみ課金（保持は別）」 (Google Cloud)

  • Azure：Log Analytics／NAT GW＋帯域の二重

    「Log Analytics の主料金は取り込みと保持」 (マイクロソフトラーニング)
    「NAT GW処理に加え帯域課金も」 (Microsoft Azure)

5. 近年の“広域障害”は前提条件（設計と運用の話）

  • AWS us-east-1（2025/10/20）

    “DNS issues affecting DynamoDB … US-EAST-1”（復旧詳細レポ） (WIRED)
    教訓：us-east-1 一極依存を避け、DR演習と外部依存（IDP/DNS/CI/CD）二経路を準備。

  • GC Paris（2023/04）水害/火災対応：単リージョン前提の脆さ。 (status.cloud.google.com)

  • Azure South Central US（2018/09）：雷→冷却喪失→長時間影響。 (GeekWire)

6. 回避パターン（要件に合わせて“削る/閉じる/分ける”）

  • NAT/egressを“設計で消す”：
    AWS=PrivateLink/VPCエンドポイント、GC=Private Service Connect、Azure=Private Endpoint。(Amazon Web Services, Inc.)
  • ログは“取り込み前に減らす”：除外フィルタ/保持分離（GC/Azure公式）。(Google Cloud)
  • 一緒に動くものは同所に：アプリとDBを分断しない（ネットワーク往復を避ける）
  • DRは費用対効果で段階化：単リージョン強化 vs マルチリージョン

7. まとめ

  • 要件で選ぶ：データ重力・レイテンシ・観測データ量・DR要件・コスト上限を数値に。
  • 費目を読む：NAT/転送/ログの設計見積りを先に。
  • 事例に学ぶ：Dropbox/37signals/NTTぷららのように、**“戻す・混ぜる”**判断は十分ありうる。(WIRED)

付録：参考リンク（一次情報・公式中心）

おまけ. “やめた方が良いかの目安”を見極めるクイック診断

6点以上なら「クラウド一択ではない」シグナル（ハイブリッド/オンプレ/コロケ＋クラウドの再検討）。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?