技術の深掘り・日常など幅広く紹介してます
サービス規模が大きくなるにつれ、ログ・メトリクス・トレースといったテレメトリデータの収集経路は複雑になりがちです。ベンダ固有のエージェントや独自スクリプトが混在していると、管理コストが増大するだけでなく、運用環境に合わせたツールの移行も難しくなります。こうした課題に対し、OpenTelemetry Collector はテレメトリデータの収集・加工・転送までを一元管理するテレメトリパイプラインを提供します。今回のブログでは OpenTelemetry Collector のコンポーネントや、パイプラインの基本的な設計・運用パターンについて紹介したいと思います。
フロントエンドアーキテクチャとして Feature-Sliced Design（FSD） と呼ばれる設計手法が注目されています。 FSD は、特にマイクロサービスを採用しているような大規模かつ複雑なシステムの開発現場において、生産性の向上が期待されており、アジャイル法や DevOps との親和性も高いとされています。FSD はシステムを構成する機能や特性（Feature）を スライス（Slice） と呼ばれる単位で細分化し、それぞれが独立性を持つことで全体の設計や変更を容易にするというものです。 スライスの考え方により、複雑な機能を把握しやすくなり、サービス規模拡大に伴うスケーラビリティを担保することが期待されています。FSD は、言語問わずあらゆるフロントエンドアプリケーションに適用できますが、今回は特に Web フロントの設計に焦点を当てて紹介したいと思います。
L2 モデルによるネットワーク設計は拡張性や高可用性の観点から、DC の弱点とされてきました。 これは L2 で使用されるプロトコルが多数のデバイス間でトラフィックを大量に送信するため、冗長化構成を取りながらもフレーミングストームを回避するための策を講じる必要があったためです。 また、従来のネットワークトポロジは、スケールインモデルであることから、ネットワーク帯域を拡張する際は、より大きくて高価な機器に交換します。 さらに、大きな機器ほど多くの機器と接続するため、故障した際の影響範囲が大きくなることが懸念されます。 そのため、DC ネットワークは拡張に伴いますます複雑化し、運用面やコスト面においてスケーラビリティは限界を迎えようとしていました。近年では、これらの問題を受け、多くの DC で IP-Clos と呼ばれる、Clos ネットワークの原則を適用した IP-fabric が採用されています。 Clos ネットワークは、L3 ベースのアーキテクチャを用いることで、ブロードキャスト等の BUM トラフィックによる帯域圧迫を排除し、安定性と拡張性を向上させます。 また、BGP と BFD はベンダに依存せず、L3 で経路を制御するため、トラブルが発生した際も、従来の IP のトラブルシューティングが適用可能になります。今回のブログでは、実際に日本で IP-Clos が採用されているヤフーにて Clos ネットワークの構築を経験してきたので、これを機に聞いた話や知見を含め、IP-Clos について調査・紹介しようと思います。