私たちは最近、Buffer でシステムの各部分が舞台裏で通信する方法をクリーンアップするための小さなプロジェクトを開始しました。簡単な説明: SQS (Amazon Simple Queue Service) と呼ばれるものを使用しています。これらのキューはタスクの待機室のような役割を果たします。システムの 1 つの部分がメッセージをドロップし、別の部分が後でそれを受け取ります。これは、同僚に「機会があれば、このデータを処理してください」というメモを残すようなものだと考えてください。メモを送信するシステムは、応答を待つ必要はありません。私たちのプロジェクト定期的なメンテナンスを実行するためです。ローカルでキューをテストし、構成をクリーンアップするために使用するツールを更新します。しかし、実際に使用するキューを計画している間に、予期せぬものを発見しました。7 つの異なるバックグラウンド プロセス (または、自動的に実行されるスケジュールされたタスクである cron ジョブ) と、最長 5 年間サイレントで実行されていたワーカーがあり、それらはすべてまったく役に立ちませんでした。これが重要な理由、それらを見つけた方法、およびその対策について説明します。なぜこれが想像以上に重要なのか、はい、不必要なインフラストラクチャ コストが発生しています。簡単に計算してみたところ、そのうちの 1 人の従業員には 5 年間で約 360 ドルから 600 ドルが支払われることになります。これは、私たちの財務の大枠から見れば控えめな金額ですが、何も行わないプロセスにとっては間違いなく純粋な無駄です。しかし、このクリーンアップを経ると、実際には金銭的なコストが問題の最も小さな部分であると私は主張します。新しいエンジニアがチームに加わってシステムを調査するたびに、「この従業員は何をするのか?」という疑問が生じます。オンボーディングに時間がかかり、不確実性が生じます。コードの一部を見つめながら、何か重要なことが行われているのではないかと心配したことがあります。「忘れられていた」インフラストラクチャでさえ、何の役にも立たないコード パスにメンテナンス サイクルを費やすことになりました。そして、それを作成した人は、何年も経つと、重要なものになってしまったのでしょうか?前に、そしてコンテキストは彼らに残されました。なぜこれが起こるのですか?指摘するのは簡単ですが、真実は、これが長期にわたるシステムでは自然に起こるということです。機能は廃止されますが、それをサポートしていたバックグラウンドジョブは、移行を処理するためにワーカーを「一時的に」起動し続け、スケジュールされたタスクはアーキテクチャの変更後に冗長になりますが、誰もチェックしようとはしません。これを行うために、私たちは実行しました。データベース全体で現在の日付と一致する誕生日をチェックし、顧客にパーソナライズされた電子メールを送信するスケジュールされたタスクでした。2020 年のリファクタリング中に、トランザクション電子メール ツールを削除するのを忘れていました。このワーカーはさらに 5 年間実行され続けました。これらはいずれも個人の失敗ではありません。プロセスの失敗です。私たちの働き方に組み込まれた意図的なクリーンアップがなければ、エントロピーが勝利します。私たちのアーキテクチャがそれを見つけるのに役立った方法多くの企業と同様に、Buffer はマイクロサービス運動 (企業が行う一般的なアプローチ) を受け入れました。数年前に、モノリスを個別のサービスに分割し、それぞれに独自のリポジトリ、デプロイメント パイプライン、インフラストラクチャを設けました。当時はそれが理にかなっていました。各サービスはチーム間の明確な境界を設けて独自にデプロイできました。しかし、数十のリポジトリを管理するオーバーヘッドが私たちの規模のチームにとってのメリットを上回ることがわかったので、サービスは論理的な境界としてまだ存在しています。これにより、発見が可能になったことが判明しました。マイクロサービスの世界では、各リポジトリは独自のアイランドです。キュー名を検索するための単一の場所はなく、どこで何が実行されているかを示す統一されたビューはありません。最終的に、すべてのキューをそのコンシューマとプロデューサーまで追跡することができましたが、コンシューマは見つかりませんでした。統合は、ゾンビ インフラストラクチャを見つけるのに役立つように設計されたわけではありませんが、それにより、実際に行ったこと孤立したプロセスを特定したら、それらをどう処理するかを決定する必要がありました。これが私たちのアプローチ方法です。まず、それぞれの起源をたどります。私たちは Git 履歴と古いドキュメントを調べて、そもそも各ワーカーが作成された理由を理解しました。ほとんどの場合、当初の目的は明確でした。つまり、1 回限りのデータ移行、廃止された機能、有用性がなくなった一時的な回避策でした。その後、それらが実際に使用されていないことを確認しました。何かを削除する前に、これらのプロセスが見逃していた重要なことを静かに行っていないことを確認するためにログを追加しました。私たちは数日間監視して、それらがまったく呼び出されないことを確認し、段階的に削除しました。一度にすべてを削除したわけではありません。予期しない副作用がないか監視しながら、プロセスを 1 つずつ削除しました。 (幸いなことに、何もありませんでした。)最後に、学んだことを文書化しました。各プロセスが元々行っていたことと、それが削除された理由に関するメモを社内ドキュメントに追加しました。そうすることで、将来のエンジニアは、何か重要なものが欠落していても不思議に思わなくなります。クリーンアップ後に何が変化しましたか。完全な影響を測定するのはまだ初期の段階ですが、これまでに確認された内容は次のとおりです。インフラストラクチャ インベントリは現在正確です。誰かが「どのようなワーカーを実行していますか?」と尋ねたら、実際、私たちは自信を持ってその質問に答えることができます。オンボーディングの会話もよりシンプルになりました。新人エンジニアは、謎のプロセスに遭遇したり、コンテキストが欠けているのではないかと疑問に思ったりすることはありません。コードベースは、5 年前に行ったことではなく、実際に行っていることを反映しています。リファクタリングを考古学と予防として扱うこのプロジェクトから得た最大の教訓: すべての重要なリファクタリングは考古学にとっての機会です。システムの奥深くに入り込み、各部分がどのように接続されているかを本当に理解しているとき、何がまだ必要なのかを疑問に思うのに最適な立場にいます。古いプロジェクトのあのキュー?誰かが 1 回限りのデータ移行のために作成したワーカーですか?聞いたこともない機能を参照するスケジュールされたタスクですか?これらはまだ実行されている可能性があります。今後のプロセスに組み込むものは次のとおりです。リファクタリング中に、しばらく見ていなかったこのシステムに他に何が影響しているかを尋ねてください。機能を非推奨にするときは、ユーザー向けのコードだけでなく、そのバックグラウンド プロセスまでトレースします。誰かがチームを離れるときは、その担当者が担当していたもの、特にバックグラウンドで実行されるものを文書化します。コードベースには、単一のバージョンに移行されていない古い部分がまだ残っています。リポジトリはまだです。私たちが整理を続けるにつれて、これらの隠された遺物がさらに見つかると確信しています。しかし今では、それらを捕捉し、新しいコードの形成を防ぐように設定されています。すべてのコードが 1 か所に存在する場合、孤立したインフラストラクチャは隠れる場所がありません。

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free