あなたのスタートアップに複雑なクラウドインフラは本当に必要か？

 (hadijaveed.me)
4 ポイント 投稿者 GN⁺ 2024-09-15 | 1件のコメント | WhatsAppで共有

複雑なクラウドインフラは本当に必要か？

  • Pieter LevelsがLex Friedman Podcastで語っていた内容を聞いて、多くの気づきを得た
  • Pieterは単一サーバーでアプリケーションを運用し、成功したマイクロSaaSビジネスを築いた
  • クラウドインフラの複雑さを避け、プロダクト・マーケット・フィットに集中することが重要
  • すべてのスタートアップに当てはまるわけではないが、複雑さのための複雑さは避けるべき

最近の観察

プロジェクト 1: Lambdaの過負荷

  • 20〜30個のLambda関数でさまざまなサービスを運用
  • SQSとLambdaを使ったバックグラウンド処理
  • CloudWatchに分散したログ

結果: デバッグが難しく、変更もしづらく、デプロイも複雑。単一のNodeJSコンテナ、またはPython Flask/FastAPIアプリとRedisで単純化できたはず

プロジェクト 2: マイクロサービスの混乱

  • Kubernetes (EKS) 上で7つの小さなマイクロサービスを運用
  • CRUDとビジネスロジックのためにサービスを分離

結果: インフラ管理により多くの時間を費やしていた。ここまでの分離が本当に必要だったのか疑問

単一サーバー構成の力

  • 現代のサーバーは強力。Hetzner、latitude.shでは低価格で高性能なVMを提供している
  • GCP VMやEC2インスタンスも妥当な価格
  • 40GB RAMとマルチコアを備えた強力な計算能力を提供
  • すべてが中央集約され、管理しやすい
  • 数百万QPSへスケールする問題は後から対処できる

単一VM構成に必要なもの:

  1. 強力なマシン (EC2、GCP VM、Hetznerなど)
  2. 安全なアクセス (HTTPS、IP制限付きSSHまたはSSM)
  3. 無停止デプロイのためのCI/CD
  4. DNS設定
  5. 定期的なデータベースバックアップ
  6. 待機VMによる冗長性の確保

Docker Compose

  • Docker Composeはローカル開発に最適
  • 複数のサービスを単一コマンドで管理可能
  • 本番環境ではあまり使われない
  • 更新時にダウンタイムが発生する可能性がある

Docker Compose Anywhere: 週末プロジェクト

  • Docker Compose Anywhereを週末のあいだに開発
  • 次の機能を提供:
    • GitHub ActionsによるワンクリックLinuxサーバー設定
    • GitHub Container RegistryとDocker Rolloutを利用した無停止デプロイ
    • 環境変数とシークレット管理 (age または sops の利用を検討)
    • GitHub Actionsによる自動化されたPostgresバックアップ
    • 単一VMでのマルチアプリ対応
    • TraefikとLet's Encryptによる自動SSL

いくつかの考慮事項

セキュリティのために:

  • 厳格なファイアウォールルールを設定する (必要なポートのみ開放)
  • SSHキーを安全に管理する (AWSではSSM、GCPではCLIを推奨)
  • セキュリティ強化のための踏み台ホストの利用
  • シークレット保護とWAFまたはCloudflareの利用を検討

データ保護:

  • 暗号化されたデータベースバックアップを安全なクラウドストレージへ転送する (例: S3)
  • 追加の冗長性のためにディスクスナップショットを定期的に作成
  • バックアップとスナップショットに対する保持ポリシーを実装

GN⁺のまとめ

  • この記事は、スタートアップが複雑なクラウドインフラを避け、シンプルな構成でプロダクト・マーケット・フィットに集中すべきだと強調している
  • 単一サーバー構成の利点と、Docker Composeを活用した簡単なデプロイ方法を紹介している
  • 複雑なインフラ管理に時間を浪費せず、中核となるプロダクト開発に集中することが重要
  • 類似した機能を持つプロジェクトとしては、Heroku、DigitalOceanなどがある

関連記事

1件のコメント

 
GN⁺ 2024-09-15
Hacker Newsのコメント

  • 多くのプロジェクトで最新技術を使おうとするチームは、質の低い成果物を作ってしまうことが多い

    • Kubernetesを理解していないのに使おうとする未熟なチームがある
    • Puppetを使ってさまざまなVM上でDockerサービスを動かしたり、Pythonバックエンドを実行する自動化プロセスを構築している
    • スタートアップはクラウドに多額の費用をかけている一方で、2017年のDevOps先駆者たちよりも悪い成果物を作っている
    • 関連ブログ記事: The Emperor's New clouds

  • 小規模なスタートアップでは、単一のVMで nginx、webapp、postgres、redis などを運用している

    • 開発者が同じ設定でローカル環境でも作業できるため、デバッグしやすい
    • 垂直スケーリングが可能で、初期段階では適している

  • SaaSを単一サーバーで始めて、複数サーバーへ拡張している

    • Kubernetesを使わなくても分散データベースを運用している
    • クラウドプロバイダーの仮想マシンより強力なベアメタルサーバーを使っている
    • 自動化ツールとして ansible と terraform を使ってサーバーを管理している

  • Kubernetesの中核機能であるデプロイ、Podサービス、ブルーグリーンデプロイなどは有用である

    • クラウドネイティブ環境でさまざまなオープンソースシステムを使うと複雑になりうる

  • 多くの人がKubernetesを学ぶために複雑なインフラを構築している

    • 大規模クライアントへスケールする際には役立つ可能性がある
    • 創業者やCTOにとってはそれほど有用ではないかもしれない

  • マイクロサービスの本でも「まずモノリスを構築せよ」と勧めている

    • 初期にはモノリスを使う方がデバッグしやすい
    • Dockerを使って初期段階を簡素化している
    • ビジネス上の必要に応じてKubernetesへ移行する

  • 複雑なフレームワークを最初から選ぶことは推奨されない

    • 自前のツールを使うことが常により効率的とは限らない
    • 標準ツールを使う方が長期的にはより効率的かもしれない

  • クラウドでは VM、ブロック/ブロブストレージ、DNS、IdP、ドメインレジストラだけを使っている

    • FaaS のようなサービスは複雑でデバッグが難しい
    • 単一VMとモノリシックなコードベースが理想的である

  • 6年間、単一の月額10ドルのVPSでプロジェクトを運用している

    • VPS技術は非常に進歩しており、信頼性が高い
    • クラウドインフラはコラボレーションや運用管理機能のために使っている

  • クラウドベースのソリューションを好むが、選択的に使っている

    • Google Cloud Platform(GCP) を使ってコストを削減している
    • Kubernetesは使っていない
    • Dockerを使ってデプロイを簡素化している
    • GCPのマネージドサービスが時間を節約してくれる