私はしばらくの間、主に Python と JavaScript でコーディングしてきました。私は Web アプリやスクリプトを構築し、機械学習にも手を出しました。しかし、私はもう少し低レベルなもの、つまりシステムやネットワークに手を染めるものを渇望していました。 Go はこの仕事に最適な言語のように思えました。

そこで、ロードバランサーを構築することにしました。これは、トラフィックを管理し、複数の接続を処理し、Go の同時実行機能を深く掘り下げる方法を学ぶ機会でした。私がどのようにやったかを詳しく見てみましょう。

宿題

コードの作成に取り掛かる前に、少し勉強する必要がありました。コンピューターがインターネット上でどのように通信するのか、使用する言語や相互検索の方法などを理解する必要がありました。また、誰がどの仕事をするかなど、コンピュータ間で作業を共有するさまざまな方法も検討しました。

次に、ワークスペースをセットアップします。適切なツールを入手し、コンピューターの準備が整っていることを確認しました。何かクールなものを作る前に、ワークショップの準備をするようなものでした。

なぜロードバランサーなのか?

さて、本題に進みましょう。なぜわざわざロードバランサーを使うのでしょうか?あなたのウェブサイトが超人気のピザ店であると想像してください。殺してるんじゃないの？しかし突然、町中の誰もがあなたのピザを欲しがるようになりました。基本的にオンラインオーブンである Web サイトが過熱し始めます。注文は山積みになり、顧客は怒り、最終的には生地の山ができてしまいます (比喩的に言えば)。

そこで、ロード バランサーが登場します。これは、非常に賢いピザの配達員を雇うようなものです。この男は、どのオーブン（またはサーバー）が空いているかを常に探しています。注文（またはリクエスト）が入ると、すぐに最も容量の多いオーブンに送ります。こうすることで、オーブン (またはサーバー) が過負荷になることはなく、全員が時間通りにピザ (または Web サイトのコンテンツ) を手に入れることができます。

つまり、ロード バランサーは Web サイトの交通警察のようなものです。たとえ事態がおかしくなったとしても、すべてがスムーズに進むようにします。

しかし、なぜそれを構築するのでしょうか? ロードバランサーはたくさんありますよね?内部でそれらがどのように機能するかを理解することは、状況を大きく変える可能性があります。さらに、独自のものを構築することは、ネットワーク、同時実行性、システム設計について学ぶのに最適な方法です。それは単に車を運転するのではなく、自分自身の車を組み立てるようなものです。関与したエンジニアリングに対するより深い評価が得られます。

嵐の前の沈黙: REST API の構築

ロード バランサーを使用する前に、トラフィックを分散するためのサービスがいくつか必要でした。ヘルスチェックとダミーワークロード用の基本的なエンドポイントを備えたシンプルな REST API を作成しました。これはロード バランサのテストベッドとして機能しました。

API の構築自体は Go の net/http パッケージを使用することで非常に簡単でした。ヘルスチェックと基本的な操作のためのエンドポイントを定義しました。ヘルス チェック エンドポイントはサーバーの健全性を示す単純なステータスを返しましたが、他のエンドポイントはワークロードをシミュレートするためにいくつかのダミー計算を実行しました。

ただし、これらのバックエンド サービスの信頼性を確保することが重要でした。ステータスを監視するために基本的なヘルスチェックを実装しました。これには、ヘルス チェック エンドポイントに定期的にリクエストを送信し、特定の時間枠内に応答がなかった場合にサーバーを異常としてマークすることが含まれていました。

念のため: ロード バランサの構築

次のステップは、実際のロード バランサーを構築することでした。これには、いくつかの重要なコンポーネントが関係していました。まず、利用可能なすべてのサーバーを追跡する方法が必要でした。アドレスや正常性状態など、各サーバーに関する情報を保存するレジストリを作成しました。このプロジェクトでは、単純なインメモリ構造を使用しましたが、運用環境では、etcd のような分散システムの方が適しています。

ロード バランサーの中核は、トラフィックを分散するために使用されるアルゴリズムです。基本的なラウンドロビン アプローチから始めましたが、特定の要件に基づいて、最小接続や加重ラウンド ロビンなどのより複雑な戦略を実装できます。

受信接続を処理するために、Go の net パッケージを使用してリスナー ソケットを作成しました。各受信接続は個別の goroutine によって処理され、同時処理が可能になりました。これは、大量のトラフィックを効率的に処理するために非常に重要でした。

バックエンド サーバーの可用性を確保することが最優先事項でした。サーバーのステータスを監視するために基本的なヘルスチェックを実装しました。サーバーに異常があることが判明した場合、そのサーバーはロード バランサーのローテーションから削除されました。ただし、実稼働環境では、アクティブ プローブや負荷ベースのチェックなど、より高度なヘルス チェックが必要になることがよくあります。

堅牢なロード バランサーの構築は、パフォーマンス、スケーラビリティ、フォールト トレランスなどの要素を慎重に考慮する必要がある複雑なタスクです。このプロジェクトは強固な基盤を提供しましたが、実稼働グレードのロード バランサには通常、追加機能と最適化が必要です。

それで、次は何ですか？

このロード バランサーの構築は、パズルを組み立てるようなものでした。タオルを投げたいと思ったことも確かにありましたが、すべてが一つにまとまったのを見る満足感にはそれだけの価値がありました。

Go の同時実行機能についてたくさん学びました。これは、複数の接続やバックグラウンド タスクを処理するために不可欠でした。リソースを効率的に管理する方法を理解することも重要なポイントでした。さらに、ネットワークの概念と回復力のあるシステムを構築する方法をしっかりと理解しました。

このロード バランサは出発点としては適していますが、道のりはまだ長いです。より高度なロード バランシング アルゴリズムを検討し、スティッキー セッションなどの機能を実装し、サービス ディスカバリ システムと統合したいと考えています。

負荷分散や Go についてさらに詳しく知りたい場合は、ぜひ試してみることをお勧めします。それは挑戦的ですが、やりがいのある旅です。以下のコメント欄でお気軽にあなたの経験を共有したり、質問したりしてください。