11 年間のホスト型 SaaS から学んだ教訓!

著者 |アレックス・ギクレスク

企画 |趙雲

Tanda（従業員管理ソフトウェア）はまもなく11周年を迎えます。ある読者から、インターネット上でアプリケーションを実行している間に私が学んだことを振り返ってみるのは興味深いだろうという提案がありました。

私は長年この職に就きました。落とし穴が多く、非常に深く、通常の操作時間は長くありません。展開、ホスティング、インフラストラクチャ管理のため、これはおそらくここ 10 年以上にわたる私の仕事の中で最も困難でイライラする部分です。

主な理由は、明らかな理由もなく落とし穴に落ちてしまうことが多く、ほとんどの場合、自分が何をしているのか分からないからです。残念ながら、多くの人が使用する本番アプリケーションの場合、それを適切に理解する時間がないこともあります。

この投稿では、私たちが経験したいくつかの段階について説明します。皆さんも同じ道をたどる場合は、最悪の部分のいくつかをスキップできると思います。

1. フェーズ 1: Heroku

まず Heroku から始めます。2012 年に、アプリケーションのデプロイを含む Ruby on Rails チュートリアルを完了すると、Heroku アカウントが作成されました。

Heroku の使いやすさは他に類を見ません。しかし、これまで Web アプリケーションをデプロイしたことがない人にとっては、これはあまり意味がありません。インターネット上のガイドの作成者は皆、これがアプリケーションを展開する最も簡単な方法であることに同意していますが、以前の方法と比べてどの程度改善されているのかはわかりません。

当時私が知っていたのはその弱点だけでした。

(1) 規範的: Heroku は、意図したとおりに使用する限り、うまく機能します。私たちの状況はこれにかなり近いです。データベース、いくつかのバックグラウンドワーカー、およびキャッシュを備えた Web アプリ。

しかし、私たちのアプリケーションは、低速クライアント (信号が弱いエリアで動作している携帯電話やタブレット) からの長時間のリクエスト (ファイルのアップロード) を時々処理する必要があるという点で、若干の違いがあります。私たちはモバイル ファイルのアップロードの先駆者ではありませんが、UnicornUnicorn を設定してそれらを処理するための正しい方法は、デフォルトとは大きく異なるため、残念に思います。私は Web アプリケーションのデプロイについて何も知らないので、これは Heroku のせいだと思いました。

最近は知識も増え、彼らがやろうとしていることの複雑さも理解できるようになりましたが、彼らのエレベーター ピッチを、アプリケーションを展開するために必要なものすべてであるとあまりにも文字通りに受け止めてしまったのは私だけではないはずです。

（2）コスト：Herokuは、独自のVPSを実行するなどの代替手段よりもはるかに高価です。もちろん、それだけではありません!しかし、私がこれを自分で導入するのは初めてだったので、私はあまり気に入りませんでした。他の選択肢と比較したときには、「$」記号しか見ませんでした。

これは理解するのが難しくありません。多くの人々のそれに対する評価は、現在では過去の評価とは大きく異なります。

いずれにせよ、コストが最終的に Heroku から移行することになった理由です。前回の Heroku 請求書は 104.95 ドルでした。 （ハハ、記憶はまだ新しいです。）

2. フェーズ2: デジタルオーシャン

Tanda に入社して約 1 年が経った頃、インフラストラクチャとコストの最適化に非常に興味を持っている大学からのインターン生がいました。彼は基本的に、Heroku にお金を払うことはお金を燃やすようなものだと私を説得しました。彼はとても素敵な人で、当時は本当に助かりました。しかし、10年経った今、正直に言って、それはひどいアドバイスでした（そして私にとって大きな負担でした）。

Heroku を廃止するということは、Heroku が行うすべての部分を置き換えることを意味します。私たちは小規模なので、完全に自動化した方法では行いません。私たちは小さすぎて意味をなさない。代わりに、Digital Ocean の UI でサーバーをポイントしてクリックするだけです。次に、デプロイする Capistrano スクリプトをいくつか設定しました。週末に、私たちはサイトを非常に短い時間オフラインにし、Heroku からデータベースをダウンロードし、それを Digital Ocean の「ドロップレット」(サーバー) にアップロードし、DNS レコードを変更しました。移行しました！

最初の Digital Ocean 請求書は 28.93 ドル、2 回目 (最初の完全な月) は 39.23 ドルでした。私は1日2ドル節約することでとても賢い行動をしていると思っていました。しばらくの間は問題なく動作していましたが、結局、月額 40 ドルで、非常に小さなアプリケーションを実行するために実際に必要なサーバーよりもはるかに多くのサーバーを購入できたのです。

成長が加速するにつれ、亀裂が見え始めました。当社の顧客基盤は 9 か月ごとに倍増しており、すぐにさらに多くのサーバーが必要になりました。これらを追加するプロセスは手動で、面倒で、エラーが発生しやすくなります。やり方はわかりましたが、余分な「ハードウェア」を追加するとなると、不安になります。

問題が本格的に現れ始めたのは、データベース サーバーが過負荷になり始めたときでした。サイトを 1 日以上デプロイしないと、Postgres のメモリが不足し、OS によって強制終了されます。自動的に修正される場合もありますが、多くの場合、誰かがアプリケーション サーバーに SSH で接続して再起動する必要があります。これは仕事中の腹立たしい部分であり、パブのトイレで携帯電話を使ってサーバーを再起動しなければならなかったときのことを今でも思い出します。

しかし、私たちが経験した Digital Ocean の最悪のインシデントは、すべてのドロップレットが一度にシャットダウンされたときでした。アカウントに入力されたクレジットカードの有効期限が切れており、バックアップカードを入力できず、アカウントの連絡先メールが監視されていない共有受信トレイに送信されています。そのため、約 1 か月間、請求リマインダーを受け取っても無視していましたが、すべてがオフラインになっていて SSH に応答していないことに気付きました。完全に彼らのせいというわけではありませんが、当時は怪しくて不安定な体制のように感じました。

ほぼ 10 年後にこれを書いていると、私たちがそれについてほとんど何も知らなかったこと、そしてどうやって逃げおおせたのかが恐ろしく、衝撃的です。もしタイムマシンがあったら、過去に戻って、Digital Ocean に 10 倍のお金を使うように自分に言い聞かせて (月額 500 ドルなら大した金額ではない)、ぐっすり眠るでしょう。

Digital Ocean を約 3 年間使用した後、当社の増大するニーズに対してプラットフォームが単純すぎると判断しました。私たちは、より大規模なクライアントとの契約を開始し、アプリケーションのホスティングにはより起業家的なアプローチが必要であると判断しました。私たちは、独自のサーバー上で独自の Postgres を管理するのではなく、管理されたデータベースを望んでいました。プラットフォームのダウンタイムを短縮したいと考えています。需要の変動に応じて自動的にスケーリングできる必要があり、さまざまなルートをさまざまなリソース グループ (…モノレポ) に負荷分散できる必要があります。これらすべてを準拠させる必要があると考えています。

後から考えてみると、この論理の多くは逆になっています。 Auto Scaling はテクノロジーであり、AWS が独占する製品ではありません。私たちはさらなる挑戦を求めるのではなく、本当に習得できるほどシンプルなプラットフォームを見つけるべきです。 (ただし、ホストされたデータベースは良いアイデアです。)

DO を廃止する唯一のもっともな理由は、DO がオーストラリアにデータ センターを持っていないことですが、そのことを非常に気にしている顧客もいます。当時はもうすぐ発売される予定でしたが、2022年末に発売されました。それまで待たなくて本当に良かったです。

ともかく。アップグレードする必要があります。ホスティング サービスをアップグレードしたい場合、誰に連絡しますか?

3. フェーズ3: AWS

私たちは真の企業である必要があり、真の企業は AWS 上でアプリケーションをホストします。それが私たちの仕事です。具体的には、Digital Ocean のインフラストラクチャをそのまま AWS EC2 に移植しました。当社は他のプラットフォーム機能を活用しておらず、AWS を他の VPS と同じように扱っています。

数か月後、AWS アカウントマネージャーを雇用する資格があることを知りました。これは、プレゼンテーションを行ったクライアントから学びました。私はとても興奮しています。アカウント マネージャーは、私たちが急速に成長し、スケーリングについて心配する必要がなくなる至福の境地に到達するのを助けてくれると思います。

最初の会議で、アカウント マネージャーがソリューション アーキテクトを連れてきました。ソリューション アーキテクトに会ったことがないので、彼らが何をしているのかよくわかりません。この人がしたことは、私たちが尋ねたすべての質問に「サーバーレスの世界でこれはどのように機能するのですか？」と答えることでした。 AWS Lambda がどのように役立つのかよく分かりませんでした (今でも分かりません) が、それが存在することを思い出させる以外には、何も役に立つことはありませんでした。

アカウント マネージャーがいることにとても興奮していたので、しばらくの間、Lambda を理解しておらず、AWS を機能させるほど賢くないことを自分が愚かだと感じていました。結局、問題は自分ではないことに気づきました。

約 1 年後に起こったもう一つの興味深い出来事は、整数が不足したことです。私たちの Rails アプリケーションはかなり古く、ほぼすべてのテーブルで主キー タイプとして整数を使用しています。新しいバージョンの Rails では、新しいテーブルを bigint として作成しましたが、ある金曜日 (13 日の金曜日でした!) に最もよく書き込まれるテーブルに新しい行を挿入できなくなるまで、チームの誰もこれが問題であることに気づきませんでした。幸運なことに、オフィスでは全員がまだ飲んでいたので、私たちは事件にかなり早く対応することができました。忘れられない物語ですね！

この事件をきっかけに、問題が発生したときにより迅速に対応できるよう、監視にさらに力を入れるようになりました (これは良い点です)。また、PostgreSQL のその他の隠れた落とし穴について、生涯にわたる偏執狂に悩まされることになり、完全に逃れることはできませんでした (それが良いことなのかどうかはわかりません)。

最近、AWS 分野における主要プロジェクトのほとんどはコンプライアンス関連のものとなっています。 SOC-2 認証を取得するには、GDPR および他の国の同等の規定のすべてのボックスをチェックする必要があります。これらすべての作業において、Amazon のロゴを指定できれば少しは楽になりますが、特定のクラウド上にあるからといって、やりたいことが何でも可能だったり不可能だったりするわけではありません。

AWS を使い始めて数年経つと、インフラ面では安定していると感じるようになりました。私たちはしばらくスタックを構築していなかったので、スタックに大きな必要性を感じていませんでした。これは 2 つの大きな成果です。私たちが直面する次の大きな課題は、組織的な知識、あるいはその欠如です。 Tanda の歴史上、「DevOps」(非常に広い定義) に携わった人は 10 人未満です。しかし、人々は来ては去っていきます。現在 2 人のサイト信頼性エンジニアがおり、1 人はもうすぐ退職する予定なので、チームにサイト信頼性エンジニアが 1 人だけいるというのはあまり魅力的ではありません。

これは、SRE が完全に独立して機能するという意味ではありません。しばらくの間、エンジニアのオンコールローテーションも行っていましたが、Rails アプリ以外の難しい部分を処理できる人材のトレーニングはあまり得意ではありませんでした。その結果、オンコール担当者はアラームの確認と監視に多くの時間を費やしますが、問題を正常に解決して修正したり、システムを大幅に改善したりできるケースはごくわずかです。

基本的に、このシステムは、ランダムなバーストと組み合わされた個々の才能の連続で構成されています。これは長期的な戦略としては不十分です。問題をデバッグするために 1 人の担当者に依存することがないように、適切なチーム構造が必要です。

4. ステージ4: プラットフォーム インフラストラクチャ チーム (PIT)

この目的のために、約 1 年前に CTO に報告するプラットフォーム インフラストラクチャ チームを作成しました。チームには各タイムゾーンに数名が所属しており、24 時間体制でオペレーション、インフラストラクチャ、関連業務を行っています。

これはハイライトでした。ついに私はオンコールでなくなりました!

また、専門知識を開発しているチームがあると実感したのは、これが初めてでした。十分な知識がなかったり、物事が恥ずかしい形で壊れたり、プラットフォームが絶えず変化したりと 10 年間心配してきた後、安定したプロフェッショナルなロードマップを持つことができてとても嬉しいです。

PIT が最初に行ったのは、進行中のインフラ プロジェクトを半分終わらせ、未使用のインフラを可能な限り削減することだった。それと、オンコールプロセスを適切に文書化することで、多くの複雑さがすぐに解消されました。これにより、チーム全員の生産性が即座に向上し、システムの所有権が与えられます。

プラットフォーム インフラストラクチャ チームの公式責任者は、CTO の Leon です。

複雑な分野で専門知識を構築するには長い時間がかかるため、これはまだ進行中の作業です。しかし、私がチームに心から自信を持ち、彼らがこの一年で成し遂げたことを誇りに思うのは、今回が初めてです。

ちなみに、当社はまだ AWS を使用していますが、だからといってプラットフォームを変更したくないというわけではありません。世の中に何があるのか​​を調べるのは常に良いことです。私たちは時間をかけて、クラウドからコロケーション データ センターへの移行について詳しく学びました。しかし、現時点ではそうする必要性を感じていません。

5. タイムマシンがあったら

もしタイムマシンがあって 2012 年に戻って自分自身に指示を与えるとしたら、何と言うでしょうか?

たくさんの小さなヒントと 3 つの大きなヒント。どちらも、面倒なことを避けるために、もう少しお金をかけることになります。

ホスティング サービスをできるだけ長く使用してください。私たちはわずか数か月で Heroku を離れましたが、それは私たち自身の損害となりました。私たちは何年もそれを続けるべきでした。重要な初期段階で私たちに代わって行うことができたはずのサーバーの管理に、あまりにも多くの時間が浪費されてしまったのです。

できるだけ早く PIT を設定してください。この分野で働きたい専門家のチームをもっと早く編成すべきでした。 Heroku の時代はそうではありませんでしたが、実際の規模に達すると、それは維持できなくなりました。

もっと自分を大切にしてください。どういうわけか、アラートを減らしたり、オンコールを効率化したり、睡眠時間を増やしたりするようなプロジェクトを優先することが常に難しいと感じています。ある日、私は突然、PIT チームを構築するために多額の予算を再配分しました。十分な睡眠をとることにはビジネス上のメリットが数多くあり、チームが取り組むべき他の事柄よりもそれを優先することは利己的なことではありません。

元のリンク:

https://ghiculescu.substack.com/p/11-years-of-hosting-a-saas