Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/04/05)へのリンクサービスメッシュは急速に、現代のクラウドネイティブスタックにおける重要部分になりつつあります。サービス間通信のメカニズム(データセンタ用語では"East-Westトラフィック")をアプリケーションコードからプラットフォームレイヤに移行し、この通信の測定と操作を中心としたツールを提供することによって、オペレータやプラットフォームのオーナは、必要性の極めて高い可視化レイヤと、アプリケーションコードにほぼ依存しないコントロールを手に入れることができます。"サービスメッシュ"という用語が業界用語集に登場したのはつい最近のことですが、その背景にある概念は新しいものではありません。これらの概念は、Twitter、Netflix、Googleなどの企業において、一般的にはFinagleやHystrix、Stubbyといった"ファットクライアント"ライブラリという形で、10年以上にわたって運用されてきたものです。技術的な観点から見れば、最新のサービスメッシュで採用されている並列デプロイ(co-deploy)によるプロキシアプローチは、DockerやKubernetesといったコンテナやオーケストレータの急速な普及によって実現した、これらのアイデアのライブラリからプロキシ形式へというパッケージの変更である、とも表現できます。最初のサービスメッシュであり、この用語を生み出したプロジェクトであるLinkerdから始まりました。2016年に初めてリリースされたLinkerdは、現在は2つの並行する開発ラインを備えています。Scala、Finagle、Netty、JVMという"Twitterスタック"上に構築されたオリジナルの1.xブランチと、RustとGo言語で一から再構築された2.xブランチです。2.0のローンチは、基盤となる実装が変更されただけではありません。長年の運用経験から学んだ豊富な教訓に基づいて、アプローチも大幅に変更されています。2.0の哲学、設計、実装の基礎になっているかを説明します。Foundationのメンバープロジェクトです。Bankといった大企業まで、世界中の企業の運用システムのアーキテクチャを支えています。Linkerdは、マイクロサービスアプリケーションに観測可能性(observability)、信頼性(reliabilityt)、およびセキュリティ機能を提供します。重要なのは、この機能をプラットフォームレイヤで提供していることです。Linkerdの機能は、実装やデプロイメントに関係なく、すべてのサービスで一様に利用であり、開発者チームのロードマップや技術的な選択とはほとんど無関係に、プラットフォームのオーナに提供されるのです。設定が可能になります。/レイヤ7のTCPプロキシを挿入することによって機能します。挿入されたプロキシはLinkerdのデータプレーンを形成し、対象サービスのすべての送受信トラフィックを処理します。データプレーンは、Linkerdのコントロールプレーンによって管理されます。コントロールプレーンは、サービスを通過するトラフィックを監視および操作するための単一のポイントをオペレータに提供する、一連のプロセスで構成されています。surface)の一部である、というものです。metrics)を報告できるのです。同じように、Linkerdは、アプリケーションのエラー処理ロジックを変更することはできませんが、障害の発生した、あるいは処理の遅延したインスタンスに対して、自動的に要求を再試行することで、サービスの健全性を向上させることができるのです。Linkerdは、接続の暗号化、暗号化によってセキュリティ保護されたサービスIDの提供、トラフィック率の移動によるカナリアおよびブルー/グリーンデプロイメントなどを実行する機能を持っています。1.xLinkerdはTwitterにおいて、世界で最初かつ最大のマイクロサービスアプリケーションのひとつを運用した経験から生まれました。Finagleが開発されました。Finagleの導入は、Twitterが大規模なマイクロサービスの採用を実現するために不可欠な部分だったのです。1.xは、Finagle、Scala、Netty、JVMで構成された、運用実績のあるTwitterスタック上に直接構築されていました。当初の目的は、Finagleの強力なセマンティクスをできるだけ広く提供することにありました。非同期RPC呼び出し用Scalaライブラリのユーザは限られていることが分かっていたので、私たちはFinagleをプロキシ形式でバンドルして、任意の言語で書かれたアプリケーションコードで使用できるようにしました。幸運なことに、同じ時期にコンテナとオーケストレータが登場したため、サービスインスタンスと一緒にプロキシをデプロイするための運用コストを大幅に削減することができました。このような理由から、Linkerdは、DockerやKubernetesなどのテクノロジが急速に普及していたクラウドネイティブコミュニティにおいて、特に大きな勢いを得ることができたのです。このようにひっそりと始まったLinkerdとサービスメッシュモデルですが、その後、急成長を遂げることになりました。1.xブランチは現在、世界中の企業で積極的に使用されており、開発も活発に続けられています。Linkerdから学んだものLinkerdが成功したもかかわらず、多くの組織が、実運用環境への導入を望みませんでした。望んではいたのですが、必要な投資額の大きさから、実行に移すことができずにいました。このようなフリクションを発生させた要因はいくつかあります。一部の組織では、JVMを運用環境に導入することに二の足を踏んでいました。JVMは特に複雑な運用面を持っており、一部の運用チームには、是非は別として、JVMベースのソフトウェアをスタックに導入することを回避する傾向がありました。Linkerdのようにミッションクリティカルな役割を果たすものについては、特にそれが顕著でした。ある組織では、Linkerdが必要とするシステムリソースの割り当てに消極的でした。MBのRSS以下にすることは困難でした。加えて、Scala、Netty、Finagleが、リソースが豊富な環境でスループットを最大化するように、つまりメモリを犠牲にするように設計されていることが、問題をさらに悪化させていました。ひとつの組織で数百から数千のLinkerdプロキシを展開する可能性があるため、このフットプリントは重要だったのです。対策として私たちが推奨したのは、プロセス毎ではなく、ホスト単位でデータプレーンを展開する方法でした。これにより、リソース消費をより適切に償却することが可能になりますが、運用が複雑になり、サービス単位のTLS証明書など、Linkerdの提供する機能の一部が制限されるという欠点がありました。(最近のJVMでは、これらの数値が大幅に改善されています。1.xのリソースフットプリントとテールレイテンシは、IBMのOpenJ9の下で大幅に削減されており、OracleのGraalVMではさらに削減されるとされています。)最後に残ったのは、複雑性の問題でした。Finagleは大規模な機能セットを備えたリッチなライブラリで、その機能の多くは設定ファイル経由でユーザに直接公開されていました。1.xは、カスタマイズ可能で柔軟性に優れる反面、学習曲線の勾配は大きくなっていました。大きな設計ミスは、基本的な構成プリミティブとしてデリゲートテーブル(dtabs)、つまりFinagleで使用されている、バックトラックと階層構造を持った、サフィックスを保持するルーティング言語を使用したことです。Linkerdの動作をカスタマイズしようとしたユーザは皆、すぐにdtabsの壁に突き当りました。その先に進むためには、相当の精神的投資をしなければならなかったのです。新たな出発Linkerdの採用レベルは上昇していましたが、2017年末になると、私たちは、自分たちのアプローチを再検討する必要があると確信していました。Linkerdの提案する価値が正しいことは明らかでしたが、運用チームに課している要件は不要なものでした。組織へのLinkerd導入を支援してきた経験を振り返って、私たちは、Linkerdが今後どのようになるべきかについて、いくつかの重要な原則を決定しました。最小限のリソース要件。プロキシレイヤにおいて、パフォーマンスコストとリソースコストを可能な限り小さくする必要がある。Linkerdは既存のアプリケーションを棄損してはならない。起動するために複雑な設定を必要とすべきではない。認知上のオーバーヘッドが少なく、操作が簡単であること。構成要素が明確で、ユーザが振る舞いを理解できる必要がある。これらの要件は、それぞれが独自の課題をもたらします。システムリソースの要件を最小限に抑える上で、JVMを離れる必要があることは明らかでした。"ちゃんと動く"ためには、ネットワークプロトコル検出などの複雑な手法に対する投資が必要になります。ためには、あらゆる点において、ミニマリズム、増分性(incrementality)、内観性(introspection)を明示的に優先することが必要です。リライトを前に、私たちは、具体的な初期ユースケースに焦点を合わせる必要がある、という認識を持ちました。これらの制限は、将来的に撤廃する必要があることも理解していました。1.xでは、コントロールプレーンとデータプレーンが、いずれも同じプラットフォーム(JVM)で書かれていました。これら2つのプロダクトは、実際には要件がまったく違います。すべてのサービスのすべてのインスタンスと共にデプロイされ、そのサービスとの間で交わされる全トラフィックを処理するデータプレーンは、可能な限り小さく、高速であることが求められます。ユーザはLinkerdを信頼して、PCIやHIPAAコンプライアンス規制の対象となるデータを含む、極めて機密性の高い情報を扱っているからです。一方のコントロールプレーンは、要求のクリティカルパスではなく周辺にデプロイされるものであるため、速度とリソースに関する要件は比較的緩やかで、拡張性とイテレーションの容易さに注目することが、より重要になります。Go言語がコントロールプレーンに適した言語であることは、早い段階から分かっていました。Go言語にもJVMと同様のマネージドランタイムとガベージコレクタがありますが、最新のネットワークサービス用に調整されているため、JVMの場合のようなコストに関わる軋轢はまったくありません。Go言語は、JVMに比較すると桁違いに運用が簡単な上に、静的バイナリである、メモリフットプリントや起動時間が改善される、といったメリットもあります。ベンチマークの結果は、ネイティブコンパイルされた言語には及ばないものの、コントロールプレーン用としては十分な速度でした。最後に、Go言語の優れたライブラリエコシステムによって、Kubernetes関連の豊富な既存機能にアクセスできるようになりました。加えて、この言語の参入障壁の低さと相対的な人気の高さから、オープンソースコントリビューションが促進されるであろう、という考えもありました。データプレーンにはGo言語やC++も検討したのですが、Rustこそが私たちの要件を満たす唯一の言語であることは、最初から明らかでした。checker)は、あらゆるクラスのメモリ関連のセキュリティ脆弱性を回避可能にすることによって、RustをC++よりもはるかに魅力的なものにしています。ネイティブコードへのコンパイルが可能であることと、メモリ管理のきめ細かい制御により、Go言語よりもパフォーマンス面で大幅に凌駕すると同時に、メモリフットプリントの制御性も向上しています。リッチで表現力の豊かなRust言語は、私たちScalaプログラマにとって大変魅力的でしたし、ゼロコスト抽象化のそのモデルは、(Scalaとは違って)安全性やパフォーマンスを犠牲にすることなく、その表現力を利用可能であることを示していました。2017年当時のRustには、ひとつの大きな欠点がありました。ライブラリのエコシステムが、他の言語よりかなり劣っていたのです。Rustを選択すれば、ネットワークライブラリへの多額の投資が同時に必要になることも、当時の私たちは理解していました。works)基本的な技術が選択されたので、次の設計目標である、"ちゃんと動く"という要件を満足するための作業に移りました。Kubernetesアプリケーションの場合、これは、機能している既存のアプリケーションにLinkerdを追加した場合でも、アプリケーションが機能しなかったり、最小限以上の設定作業が必要になることがない、という意味になります。この目標を達成するために、いくつかの設計上の選択を行いました。私たちはLinkerdのプロキシを、プロトコル検出が可能なように設計しました。TCPトラフィックをプロキシすると同時に、使用されているレイヤ7プロトコルを自動的に検出することができるのです。pod作成時のリワイヤリングと組み合わせることで、任意のTCP接続を作成するアプリケーションコードによるコネクションを、ローカルのLinkerdインスタンスを通して透過的にプロキシ処理します。その接続がHTTP、HTTP/2、gRPCのいずれかを使用している場合、Linkerdは自動的に動作を変更し、成功率の報告、べき等要求の再試行、要求レベルでのロードバランシングなどによるレイヤ7セマンティクスを実現します。これらすべてが、ユーザの設定を必要とせずに実施されるのです。アウト・オブ・ボックスでできる限り多くの機能を提供することにも尽力しています。1.xでは、プロキシ毎に豊富なメトリクスを提供していましたが、これらメトリクスの集計とレポート作成はユーザに任されていました。2.0では、期限の設定された小さなPrometheusのインスタンスをコントロールプレーンの一部としてバンドルすることで、アウト・オブ・ボックスの状態で、集約されたメトリックをGrafanaダッシュボード形式で提供できるようにしています。同じメトリクスをUNIXスタイルのコマンドでも使用可能にすることで、オペレータがコマンドラインから、運用中のサービスの動作を監視できるようにしました。プロトコル検出と組み合わせることで、プラットフォームオペレータは、設定や複雑な設定をすることなく、Linkerdから豊富なサービスレベルのメトリックをすぐに取得することができます。シンプル使いやすさに関する目標とは相反しますが、これが最も重要な目標でした。Hickey氏の講演が参考になりました。)Linkerdはオペレータ向けの製品である、ということを、私たちは知っていました。クラウドプロバイダが運用してくれるサービスメッシュとは対照的に、Linkerdはユーザ自身による運用が前提なのです。area)を最小限に抑えることが最優先事項である、ということを意味しています。1.xを導入する企業の支援を長年続けてきた経験から、この件に関しては、具体的なアイデアを得ることができました。動作内容を隠蔽したり、過度に神秘的に思われてはならない。内部状態は検査可能でなければならない。コンポーネントは明確に定義され、分離され、明確な境界を持たなければならない。この目的にかなう設計の選択肢を、私たちはいくつか作り上げました。UIを駆動し、プロキシAPIサービスがデータプレーンとの通信を処理するというように、コントロールプレーンを自然な境界で分割しました。applyを通じてクラスタに適用する、Linkerdのダッシュボードは、ルック・アンド・フィールをKubernetesのダッシュボードに合わせる、といった具合です。節度を保つことによって、複雑さも回避しました。"サービス"とは何かについて、独自の定義を導入するのではなく、デプロイメントやPodといった、Kubernetesの中核をなす名詞を流用しました。シークレットやアドミッションコントローラなど、可能な限り既存のKubernetes機能を基盤に使用しています。クラスタの複雑性に大きく影響することが分かっていたので、カスタムリソース定義の使用は最小限にしました。最後に、広範な診断機能を追加することで、オペレータがLinkerdの内部を検査し、期待する状態であることを検証できるようにしました。コントロールプレーンをメッシュ化(すなわち、各コントロールプレーンポッドに、送受信されるすべてのトラフィックをプロキシするデータプレーンサイドカーを配置)することで、Linkerdの豊富なテレメトリを使用して、自分たちのアプリケーションと同じように、Linkerdの状態を理解し、監視することを可能にしました。check、といったコマンドも用意しています。Linkerdを簡単で不思議なものではなく、明確で観察可能にするために、私たちはできる限りのことをしたのです。2.0をローンチしました。提供価値(バリュープロポジション)は基本的に同じですが、使いやすさ、操作の単純さ、リソース要件の最小化といった部分に重点を置いた結果、1.xとはかなり異なる製品形状になっています。アプローチの成果は、6ヶ月を待たずに現れました。それまで1.xブランチの採用が叶わなかった多くのユーザが2.xを採用したのです。Rustを選択したことは、大きな関心を集めました。ギャンブルのようなものでした(実際、初期のバージョンは、Linkerdブランドを傷つける不安から、"Conduit"という名称でリリースしていました)が、その賭けに勝ったことは、今となっては疑いありません。2017年以降は、Tokio、Tower、HyperといったコアRustネットワークライブラリに多くの時間を割いてきました。2.0のプロキシ("linkerd2-proxy"という、そのものの名前で呼ばれています)をチューンして、リクエストフローにおけるメモリのアロケーションがデアロケーションで償却されるようにしました。これにより、レイテンシ分布が非常にシャープなものになりました。Linkerdのプロキシは、1ミリ秒未満のp99レイテンシと、10MBをはるかに下回るメモリフットプリントを特徴としています。1.xよりも1桁小さい値です。Linkerdには現在、ユーザとコントリビュータによる活気あるコミュニティがあり、プロジェクトの将来は有望です。2.xブランチに関わる50人以上のコントリビュータ、週毎のエッジリリース、活発でフレンドリなコミュニティSlackチャンネルを持ったことで、私たちは、これまでの努力を誇りに思うと同時に、単純さ、使いやすさ、リソース要件の最小化という設計思想を維持しつつ、ユーザの抱える現実的な課題を解決し続けたいと願っています。Morgan氏は、クラウドネイティブ環境向けのオープンソースのサービスメッシュ技術の構築に注目するスタートアップである、Buoyantの共同創設者兼CEOです。Railsアプリから、高度に分散化されたフォールトトレラントなマイクロサービスアーキテクチャへの、Twitterの移行に尽力しました。その後はPowerset、Microsoft、Adap.tvのソフトウェアエンジニアを経て、MITREの研究科学者となり、スタンフォード大学でコンピュータサイエンスの修士号を取得しています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。