手元のシステムを徹底的に使い倒せ

• この記事では、著者がSaaSアプリケーションでPostgresの性能を管理した経験について述べており、データベースが負荷をさばくのに苦労していた。
• 著者のチームは、データベースが忙しくなりすぎるたびに、より大きなインスタンスへ置き換えることで垂直スケールしていた。しかし、すでに最大のインスタンスを使っており、過負荷状態に陥る寸前まで来ていた。
• 可能な解決策として、書き込みを独立したデータベースクラスターへシャーディングすることと、モノリスを複数の連携したサービス（マイクロサービス）に分割することの2つが提案された。
• どちらの解決策も容量を増やし、耐障害性や運用レジリエンスに関する興味深い選択肢を提供するが、複雑さを大幅に増やしてしまう。
• 著者は、複雑さの増加に伴う本当のコストは注意力であり、それが以後のあらゆる技術的意思決定を複雑にすると主張する。
• 著者は、複雑さを大きく増やす前に、一般にはワークロードを調整したり、性能をチューニングしたり、何らかの形でシステムを補強したりすることで、既存システムからわずかな追加性能を「絞り出せる」余地があると提案する。
• 彼らのケースでは、重いクエリの最適化、Postgres設定のチューニング、そして一部の高コストな読み取り専用クエリをレプリカDBへオフロードすることによって、データベースの週次CPU使用率の最大値を90%から30%に下げた。
• 著者は、複雑さは必要であり避けられない場合もあると結論づけつつも、できる限り長く複雑さの増加を先送りし、まずは既存のシステムから最大限の性能を絞り出すのが望ましいと締めくくっている。

[GN⁺]

Hacker Newsの意見

• 記事は、置き換えやアップグレードを検討する前に、現在のシステムの潜在能力を最大限に引き出すことの重要性を強調している。
• チームは、たとえ完璧ではなくても今あるものを活用し、既存のリソースで目標を達成する方法を見つけるべきだと提案している。
• データベースでJOINを使わないようにアプリケーションを設計するという考え方について論じ、ストレージは安価であり、すべてを非正規化してトランザクション内で更新すべきだと提案している。
• ホットパーティションを防ぐためにUUIDを使うことが提案されており、いずれ限界に達する可能性のある整数に依存する代わりに、水平スケールできるとしている。
• あるチームが、ハードウェアや複雑性をさらに追加する代わりに、問題解決の方法を変えることでシステム性能を大幅に改善した成功事例を共有している。
• 記事は、モノリスを一度に複数の連携サービスへ分割することに反対し、代わりに最も大きな効果をもたらす分割を見極めることを提案している。
• ORM上に構築されたWebアプリでクエリを最適化することの重要性を強調しており、改善の余地はしばしば大きいとしている。
• マイクロサービスシステムで作業することの精神的負担と複雑さについて警告し、これらはしばしばダウンタイムと混乱を引き起こすと示唆している。
• 効率性（損失を最小化し、複雑さを避けること）と最適化（複雑さを追加する代償として専用アルゴリズムを使うこと）の違いを区別している。
• より複雑なインフラへの移行に対する懸念を共有し、それが誰もが期待する万能な解決策ではないかもしれないと示唆している。
• とくにリソースが限られていて、システムがそれほど重要ではない場合には、複雑さよりもシンプルさを支持している。
• 最後に、記事はテナント（顧客）ごとのシャーディングを、スケーラビリティ問題に対する潜在的な解決策として論じている。