牛はペットではない」という言葉を初めて耳にしたとき、それは私がクラウド向けの開発をする際に常に意識していたものの、表現する言葉がなかったコンセプトを説明するのにぴったりの比喩だった。 クラウドインフラから個性を排除し、リソースを家畜のように名もなくダイナミックに扱うべきだという考え方だ。 資源は常に行き来しているため、名前を付け、餌を与え、ペットのように世話をする時間はない。

スーパーヒーローやディズニーのキャラクター、あるいはドクター・フーの悪役のような、極めてオタク的な名前を冠したサーバーを設置している場所に行ったことがある人は多いだろう。 しかし、スケーラビリティについて話し始めると、キャラクターは十分に速く想像することはできない。 アプリケーションの新しいインスタンスを何度も立ち上げるために必要な手作業は言うまでもない。 ミュサーク用にクラウドインフラを開発する際、最初の目標はインスタンスに直接接続しないことでした。 これは、アプリケーションをどのようにデプロイし、ステートを管理し、発生した問題をデバッグするかという疑問に答えるための素晴らしい出発点だと感じた。 これは主に、ミュゼルクの黎明期にどのように事業規模を拡大し始めたかについての定性的な考察である……。 だから、超オタクの皆さんのために、ロードバランシング、キャッシュ、インフラストラクチャー・アズ・コードなどの詳細については説明しない。

アプリケーションの展開

スケーリングの最も重要な側面は、アプリケーションをプログラムでデプロイできることだろう。 それさえできれば、あとは施設に過ぎない。 ここでの明白な答えはDockerだ。 より高度な答えにはKubernetesやTerraformが関わってくるが、それはまた別の日にしよう。 コンテナ化されたアプリケーションでは、依存関係、バージョン、オペレーティング・システム、前もって行う必要のあるあらゆる設定を制御できる。 つまり、必要なのはコンテナを動かすプラットフォームだけだ。 この利点は、このプラットフォームが何でもあり得るということだ！ このコンテナは、dockerをサポートする場所であればどこでも、我々が必要とするものを全く同じ方法で実行する。 これらのコンテナを1つ起動するプロセスが自動化されれば、あとはいくつでも自由に起動でき、ロードバランサーがトラフィックを適切にルーティングできるようになる。

国家管理

次に、本質的にゴミであるサーバー・インスタンスの状態をどのように管理するかという問題がある。 ディスクへの書き込みは、インスタンス間ですべての情報が失われるため、問題外だ。 NFSはどうなんだ？ これはもっともな解決策かもしれないが、プロビジョニングされたIOP（クラウドでは高価）がなければ遅すぎる。 それに、もっとうまくやるべきだ！

実際、これがデータモデルを磨き上げる出発点となり、ある種のETLの第一段階を考え出さざるを得なかった。 データを取り込む際、アプリケーションが一貫した方法でデータにアクセスできるように、データをどのように保存すればいいのだろうか？ すべてのデータが一か所に集まれば、それを「真実の情報源（Single Source of Truth）」として使うことができる。 データベースをSSOTとして使うことは、それ自体が複雑だ。 スケーラブルなインフラ全体でステートを管理するための本当の教訓は、できる限りステートを避けることだ。

デバッグ問題

最も一般的なのは、個々のインスタンスにログインする必要があるのは、通常、何が問題だったのかを把握するためである。 リソースがスケールし始めると、エラーは4台、10台、あるいは理論的にはn台のインスタンスのいずれかで発生する可能性があるため、いずれにせよこれはますます難しくなる。 では、どこで問題が起きているのかを把握し、それを解決するにはどうすればいいのか。 アプリケーション全体で監視すべきことはいろいろある。 ユーザーエクスペリエンス、リソースの傾向、ロード時間などはその一例だ。 私が思うに、最も重要なのはエラーログである。

エラーが発生したら、それを知らせてほしい。 最初のパスでは、ロガーを使うべきである。 ロガーは、ログの種類ごとにカテゴリーを割り当て、重大度順に並べることで、新しいログの作成方法を標準化することができる。 一般的なカテゴリーには、DEBUG、INFO、ERRORなどがある。 この例では、DEBUGレベルのログは、何が起こったかを解明するのに役立つ情報かもしれないが、常に目を通す必要はない。 INFOレベルのログは、もう少し深刻度を増している。 これらのメッセージは、使用状況をリアルタイムで確認できるよう、常に見ておきたいものだ。 ERRORログは、最も深刻なもので、警告を発することができる。 ERRORが記録されたときに報告するようにシステムを設定することで、即座に対処することができます。 INFOログとDEBUGログを使って、何が起こったかを特定することができる。 正しく実行できていれば、これらのログはアプリケーションが動作しているマシン固有の情報を持っているので、ハードウェア固有の問題に対処することができる。 すべてのアプリケーションのすべてのマシンからログを収集できるようになれば、各アプリケーションを対象としたダッシュボードを構築し始めることができる。 利用状況やハードウェアの指標と組み合わせることで、関連するすべての情報を一元的に見ることができる。

ご自身のクラウドインフラを考える上で、少しでも参考になれば幸いだ。 私たちは建築の改良を続けながら、もっと多くのことを分かち合いたいと考えている。 私たちは日々テクノロジーを進化させ、ETLワークフローの改善や、私たちが生成したデータで行っている膨大な処理への統合に努めています。 それまでは、私たちがこの最後のフロンティアへの旅の途中で学び、実践してきたことを記事に埋め戻していくつもりだ。