2023年、栄光まではわずか11MB/秒

 (thmsmlr.com)
2 ポイント 投稿者 GN⁺ 2024-04-08 | 1件のコメント | WhatsAppで共有

クラウドコストの真実

  • クラウドサービスは安価だという認識があるが、実際にはユーザーが過大なコストを支払っている可能性がある。
  • AWSはAmazonの利益の大半を生み出しているが、これはクラウドサービスが実際には高価であることを意味しているのかもしれない。

第一原理からの計算

  • 上位1000サイトの1つを作りたいなら、たとえば businessinsider.com のように月間2億人の訪問者と4億ページビューが必要になる。
  • HTMLドキュメントだけでも月間30TBの帯域幅が必要だが、これは毎秒11MBにすぎず、現代のハードウェアでは非常に低い基準だ。

レイテンシへの理解

  • 光の速度で考えると、地球の反対側まで往復するには約200msが必要だが、実際には約300msかかる。
  • CDNを使ってJS、CSS、メディアを配信すれば、サーバー処理時間を300ms短縮し、ユーザーのそばにサーバーを置くのと同じような効果を得られる。

エッジ技術の限界

  • エッジ技術は、第2世代サーバーレス技術の発展にもかかわらず、データベースの問題を解決できていない。
  • ほとんどの複雑なページではデータベースクエリが必要であり、これがレイテンシを増加させる可能性がある。

コストに関する考慮

  • Hetzner.com は、AWS EC2と比べてはるかに安価なサーバーと帯域幅のコストを提供している。
  • クラウドベンダーは初期段階では多くのものを無料で提供するが、スケール時にはコストが大きく増加する。

現実的な状況

  • 特定のユースケースでない限り、ほとんどのWebサイトやSaaSは単一サーバーで動かすことができ、そのほうが安価で保守も簡単だ。
  • SQLiteをローカルで使い、CDNを通じてCSS、JS、画像をキャッシュし、サーバーレンダリングによって性能を向上させられる。
  • 複雑なDockerや仮想化がなくても十分にスケール可能であり、管理もしやすく、コストも安い。

GN⁺の意見

  • この記事は、クラウドサービスの費用対効果に関する一般的な信念に疑問を投げかけ、ユーザーが実際に必要な以上のコストを支払っている可能性を指摘している。
  • クラウドサービスのコスト構造と比較して、従来型の単一サーバーホスティングが依然として有効な代替案になり得ることを示している。
  • サーバーレス、Docker、水平スケーラビリティといった技術があらゆる状況で必要なわけではなく、ときにはより単純なアプローチのほうが優れた性能とコスト削減をもたらし得ることを強調している。
  • データベース最適化と地域的な配置の重要性を強調しており、これはクラウドサービスが提供するものと同等またはそれ以上の性能を実現できることを示唆している。
  • 技術選定で考慮すべき点として、実際のトラフィックと性能要件を評価し、費用対効果を踏まえてクラウドの代わりに従来型サーバーホスティングを検討できる。

関連記事

1件のコメント

 
GN⁺ 2024-04-08
Hacker Newsの意見

  • ホスティング事業の経験

    • 過去のホスティング事業では、顧客の要求に応じて複雑なシステムを提供していた。
    • AWSに対抗するためにAPIベースのクラウドホスティングプラットフォームを開発したが、2012年に売上がピークを迎えた。
    • 顧客はAWSベースのより複雑なソリューションを求めており、単純なサーバーを信頼しなかった。
    • 会社はブートストラップ方式で運営されており、AWSのコストリスクを負う必要性を理解していなかった。
    • AWSは、ソフトウェア開発者の世代に深く根付いた「賢さ」への志向によって好まれている。

  • トラフィック分析の誤り

    • トラフィックは均等に分散されず、ピーク時の帯域幅要件は平均値よりはるかに高い。
    • 実際のサービスでは、TCPおよびTLS接続の確立に複数回の往復が必要であり、ユーザー体験において応答時間が重要となる。

  • サーバーエラーとトラフィック

    • 500 Internal Server Error は、サーバーが想定以上のトラフィックを処理していることを示す。

  • サービス拡張へのアプローチ

    • 不要なスケーリングを避け、必要なときにだけ構築するのが望ましい。
    • パフォーマンス問題が発生した時点で対応するのがよい。

  • AWSの利点

    • AWSを使うと、サービス障害時に言い訳の余地が生まれる。

  • クラウドアーキテクチャに関する議論

    • これはクラウドアーキテクチャの必要性をめぐる論争ではなく、代替案を提示するための手段である。
    • サーバーがダウンした場合の可用性の問題は、別の方法で解決できる。

  • SQLiteと垂直スケーリング

    • SQLiteの代わりにセルフホストのPostgresを使うこともできるが、より多くのセットアップ労力が必要になる。
    • 全体のグローバル状態をメモリに保持し、ディスクにスナップショットを保存するアーキテクチャも可能である。

  • APIとSQLiteデータベースの組み合わせ

    • SQLiteは単一スレッドで多くのクエリを処理できる。
    • API側でメモリキャッシュを使い、静的ページについてはデータベースをスキップしてパフォーマンスを向上させることができる。

  • 単一サーバーの可用性問題

    • 単一サーバーでサービスを運用すると、計画外のダウンタイムが発生する可能性がある。
    • データ復旧時間とデータ損失量を考慮する必要がある。

  • クラウドへの移行と可用性

    • クラウドへの移行は、しばしば同調圧力のように感じられる。
    • 可用性の観点では単一サーバーはリスクになり得るため、CDNとクラウドを賢く組み合わせて使うのがよい。