投稿者: Wes Jones

今月の第一金曜日のプレイリストは、シニア・ソフトウェア開発者のウェス・ジョーンズがお送りします。

Muserkでは、DSPやアーティストのストアフロントについてよく話しています。 今、アート、ファッション、カルチャー、音楽にとって最も影響力のあるメディアがTikTokであることは周知の事実だ。 私にとっては、新しい音楽を見つける方法が完全に変わった。

数年前、大学に行く前はメタルバンドをやっていたので、他のアーティストと一緒に演奏したり、旅に出たり、新しい人に会ったりすることが多かった。 たぶん、知り合った人からの推薦だったり、オープニングだったり、このバンドのメンバーがあのバンドで演奏していたとか。 数年前までは、自分が何に興味があるかに基づいて、新しい音楽を強制的に送り込む道をキュレーションすることができた。 Pandoraは大きな助けとなり、アメリカではついにSpotifyを手に入れたが、それでも新しい音楽を見つけるにはかなり積極的なアプローチだった。 NOW That’s What I Call Music』を覚えているだろうか？ 私はそのアイデアを真似して、毎年新しい音楽を見つけては「NOW 30XX」というプレイリストに追加し、その年に見つけたすべての音楽を聴くことに時間を費やしていた。 私は現在もこれを続けていて、NOW 3021（現在の年にしているが、1000年先の未来）にいる。

TikTokでは、他のコンテンツを消費している間に新しい音楽が流れてくるので、より受動的なアプローチで新しい音楽を見つけることができるようになった。 私がTikTokで初めて知った様々な曲とアーティストのプレイリストです。

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

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

アプリケーションの展開

スケーリングの最も重要な側面は、アプリケーションをプログラムでデプロイできることだろう。 それさえできれば、あとは施設に過ぎない。 ここでの明白な答えは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ワークフローの改善や、私たちが生成したデータで行っている膨大な処理への統合に努めています。 それまでは、私たちがこの最後のフロンティアへの旅の途中で学び、実践してきたことを記事に埋め戻していくつもりだ。

多くの新興企業がそうであるように、ムサークも完全なリモートチームとしてスタートした。 私たちのビジネスが固まると、ワークフローが増え、コラボレーションの重要性が増した。 論理的な次のステップは、できるだけ多くの人々を1つの場所に集めることだった。 しかし、世界中にチームメンバーがいるため、会社全体がナッシュビルに移転するとは考えられなかった。

COVID-19の渦中で、私たちはチームを遠隔地に移さなければならなくなった。 オフィスでの生活にも慣れ、チームも大きく成長した。 完全なリモートチームという遠い記憶は失われてしまったのだろうか？ これを克服することがどれほど大きな挑戦になるのか、私たちには確信が持てなかった。 幸運なことに、ナッシュビルの外にはまだチームのメンバーがいて、ずっと偶然にもこの準備をしていた。

オフィスは常に私たちのハブとして機能してきた。 四半期に一度、ナッシュビルに1週間集まり、会社がやってきたことをすべて共有するのだが、各グループの努力の分担は明らかだ。 各チームはそれぞれのことに取り組んでいて、その知識の一部は日々伝わってこない。 その必要がないからだ。 コミュニケーションはリモート・チームを円滑にする鍵であり、他の優れたチームと同様、過剰なコミュニケーションに努めるべきだ。 しかし、その過剰なコミュニケーションは、効果的でなければ、すぐに注意散漫になりかねない。

オフィスで働いている私たちは、自分たちにとって重要な情報ストリームは何か、それらをどのように分け、どのように重要なものを利用するかを考えてきた。 ミュゼルクで起きているすべての会話を購読し、邪魔になったらミュートするために、私たちはチャットチャンネルをできるだけ細かくしています。 ディスカッションは直接会うよりもチャットで行われることが多く、その場にいなかった人のために結果を掲示する習慣がある。 私たちは、そのトピックに関心がある人にもない人にも、気軽にミーティングの招待状を送る。 スケジュールされたミーティングでは、カレンダー内にビデオリンクが自動作成され、タブレットをホワイトボードとして使用するために参加する。 COVID-19のせいでオフィスに行けなくなったとき、私たちはコラボレーションにどのような支障が出るか心配した。 知らず知らずのうちにリモートファーストの文化が醸成され、リモートの経験のない新入社員でもシームレスに適応することができた。

では、オフィスは不要になったのだろうか？ それがなかったら、チームとしての自分たちを見つけ出すことはできなかっただろう。 コミュニケーションに関するレッスンは、もっと努力が必要だったかもしれないし、発展させるのに時間がかかったかもしれない。 私たちはうっかりしていたが、災害への備えについて、将来にも引き継げる貴重な教訓を得た。 オフィスに戻っても、この瞬間は頭の片隅に残るだろう。 私たちがこのような状況になることは二度とないかもしれないが、もしそうなったとしても、移行は同じようにシームレスなものになるだろう。