サービスメッシュのLinkerd、新バージョン2.0をリリース
サービスメッシュはコンテナ、コンテナオーケストレーションに続くIT業界の新しいパラダイムとして注目されている。アプリケーションを複数のコンテナに分散させ、それらを協調させることでよりクラウドネイティブなシステムを実装するのが目的だ。アプリケーションロジックが分散されることで、コードの改修や機能追加などが迅速に行え、急激な負荷の増大に対しても任意のPodを並列化し、負荷の分散を行うことができる。
一方で、リソースが分散されることにより発生する遅延などの不具合といった課題も想定される。その対策として、従来から行われているログの分析だけでなく、Pod間のトラフィックの追跡を可能にするOpenTracing、Jaeger、Zipkinなどの分散トレーシング技術の開発が進んでいる。またGrafanaなどを使った可視化においても多くのユースケースが存在する。このようにサービスメッシュは、今、デベロッパーの注目を集めている最も熱いエリアと言えるだろう。
Kubernetesをベースにしたサービスメッシュのためのソフトウェアと言えば、GoogleやIBMなどがコントリビューションを行っている軽量ProxyであるEnvoyを使ったIstioが有名だが、サンフランシスコのベンチャーであるBuoyantが開発をリードするLinkerdも、多くのユースケースで使われているという。そのLinkerdが、最新バージョンの2.0をリリースした。
参考:Announcing Linkerd 2.0: from service mesh to service sidecar
2.0のリリースを発表したこのブログによると、Linkerdは完全に書き直され、1.0よりも高速かつ小さくなったという。Proxyとして機能するデータプレーンはRustで書かれている。またそれを制御するコントロールプレーンはGoで書かれ、99%のトラフィックにおいて1ms以下の反応を可能にする高速性を実現しているという。
参考:Linkerd 2.0 Now In General Availability: From Service Mesh to Service Sidecar
LinkerdをホストするCloud Native Computing Foundationからも上記のリリースが出ているように、Istioで実装されていたmTLS(Mutual TLS)もサポートしており、これでEnvoyを使うIstioとほぼ同等の機能になったとみていいだろう。
より詳細に知りたい場合は、GitHubのリポジトリーを参照して欲しい。
参考:https://github.com/linkerd/linkerd2
もともと軽量ProxyだったConduitがRustで書かれていたこと、ConduitがLinkerdにマージされるという発表が2018年7月であったことなどを考えると、ConduitがLinkerd 2.0のデータプレーン、つまりProxyとして置き換わったということだろう。元々、サーバー単位のProxyとして使われていたLinkerdを、Pod内に配置するサイドカーモードで実装する時に、軽量化と高速化は必然の要求だったとすれば、Conduitの軽量ProxyとLinkerdのコントロールプレーンを組み合わせるのはベストの発想だ。
ここでサイドカーモードについても少し解説をしよう。コンテナをベースにしてサービスメッシュを実装する際の大事なコンセプトが「サイドカー」である。これはコンテナ/Podが稼働するサーバー単位に通信を代替するProxyを導入する方法とは異なり、コンテナが格納されるPodの中にProxyが共存する形で導入されるものだ。ここでは、Pod内のコンテナが仮想インターネットインターフェースを通じて外部のトラフィックとして接続される。コンテナからのトラフィックを一旦、Proxyが引き受けてから外部と接続することで、トレーシングやレイテンシーの可視化が可能になる。
つまりアプリケーション全体を見通せば、サイドカーとして実装されるProxyへの通信オーバーヘッドは分散化が進めば進むほど大きくなる。そのため「いかにProxyを高速化し、同時にメモリーフットプリントを小さくするのか?」は大きな問題である。Linkerd 2.0は元々軽量であることを目指したConduitをベースにしているだけに、その部分ではアドバンテージがあったと思われる。
また導入に際して、アプリケーションを変更する必要がない点や、Kubernetesクラスターの再起動が不要なことも含めて、大きく進化したバージョンとなった。使い方も以下のリンクにあるGetting Started Guideが良くできているので、ぜひ試していただきたい。
クラウドネイティブなシステムがコンテナからKubernetes、そしてサービスメッシュに進化することで、開発と実装の速度が向上し、セキュリティを担保しながら同時に急激な負荷の増大にも耐えられるようになってきたことは喜ぶべきことだ。その反面、これまでのモニタリングや運用の方法では対応できず、新たなツールや方法論が必要になってきている。また利用されるソフトウェアについても次々と新しいプロジェクトが立ち上がり、ユーザーにとっては何を選ぶのか? が重要な時代になってきた。
サービスメッシュの構築を検討する際に、これまではIstio一択という状況だったが、今回の最新バージョンリリースによって、Linkerdも重要なプレイヤーに躍り出たと言っていいだろう。この他にもRPCではgRPCだけではなくAlibabaが開発をリードするRPCフレームワークのDubboが登場しているし、Pod内でパケットフィルターを実装するCiliumも注目されている。さらに前述の分散トレーシングではOpenTracing、Jaeger、Zipkinなどがお互いに競争している。まさに日進月歩の状態である。
参考:iptablesを置き換えるBPFをコンテナネットワークに使うCilium
2018年後半に開催されるKubeCon(上海が11月13日~15日、シアトルが12月11日~13日)に向けて、多くのプロジェクトやユースケースが発表されるだろう。引き続き注目していきたい。
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- Puppet、インフラ自動ソフトウェア「Puppet Bolt 1.0」リリース
- テスト駆動インフラ/インフラCIの潮流、Serverspecが果たす役割
- 構成管理ツールとしてAnsibleを選ぶべき理由
- エンカレッジ・テクノロジ、証跡管理ソフトウェア「ESS REC」のUNIX/Linux向けエージェントの最新版を発表
- エンカレッジ・テクノロジ、証跡管理ソフトウェア「ESS REC」のUNIX/Linux向けエージェントの最新版を発表
- クラウドでの設定管理ツールPuppet
- 自動化・省力化のためのSerf入門
- NTTデータ先端技術、システム構築や設定変更の自動化を効率的に実施するためのオーケストレーションフレームワーク「Cloudify」の取り扱いを開始
- Serverspecの概要からインストールまで
- Red Hat Summitで脚光を浴びたAnsibleの担当VPが語るオートメーションツールに必要な要件とは?