Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/04/20)へのリンクKubernetesは、企業におけるコンテナオーケストレーションのデファクト標準になりました。コンテナ化されたアプリケーションの管理を簡単なものにする、多くの機能を提供しているからです。一方でKubernetesには、いくつかの新たな課題もあります。その最も大きなものは、大規模な分散システムを効果的に管理するために、複数のKubernetesクラスタを展開し管理する必要があることです。設計とコーディングが完了したアプリがあり、コンテナを構築し、後はそれらを実行するのみ、という状況を想像してください。コードからアプリを実行するのは気分のよいものですが、コンテナ化されたアプリケーションを開発した経験がある人なら誰でも知っているように、それは当初思っていたほど単純な作業ではありません。本番環境にデプロイする前には、さまざまな開発/テスト/ステージのサイクルがあります。拡張性の問題もあります。水平方向のスケーラビリティ、レジリエンス、あるいはエンドユーザとの距離が近いなどの理由で、運用アプリケーションをさまざまな場所で実行することが必要になるかも知れません。環境が増えれば、(クラスタの)問題も増える関連スポンサーコンテンツまったく新規のアプリケーション構想であっても、複数のデプロイメント環境が必要になるまでには、それほど時間がかからないのが普通です。既存のアプリケーションのマイグレーションであれば、さまざまなセキュリティドメイン、さまざまな組織/課金、さらには特定のクラウドベンダのマシンラーニング用ツールキットとの親和性など、さらに多くの課題に直面することになります。この問題を解決する最も一般的な方法は、複数のKubernetesクラスタを立ち上げて、それぞれ専用の環境でアプリケーションコンポーネントを実行することです。セキュリティの高いドメインでは、Kubernetesのロールベースアクセス制御(RBAC)や監査機能を広範に利用することになるでしょう。テスト環境ならば、運用時の挙動を数多く再現すると同時に、デバッグや検査が容易になるような設定が必要になります。したら私と同じように、Dockerの設定を開いて、単にKubernetesのチェックボックスにチェックするだけかも知れません。使いやすさと短命(ephemerality)が、ここでは最も重要になります。少なくとも数セットのKubernetesクラスタを立ち上げて、それぞれでマイクロサービスをホストすることになるでしょう。同じクラスタ内のこれらマイクロサービス間の通信は、サービスメッシュによって拡張することが可能です。Istioがレジリエンス、セキュリティ、可観測性を向上させる共通の通信パターンを提供してくれます。クラスタを越える場合についてはどうでしょうか?Kubernetesクラスタの複数運用を恐れる必要はありませんが、複数のクラスタを実行する場合には、その上に優秀なアプリケーションを容易に展開できるように、クラスタ間の通信や対話の方法について検討しておく必要があります。Istioのようなサービスメッシュは、そのようなマルチクラスタ通信を容易にしてくれます。Istioにはマルチクラスタのサポートがあります。1.1では新機能が追加されていますし、将来さらに多くの機能が追加される予定です。サービスクラスタを導入して、複数のクラスタ間の通信を簡素化する方法も検討すべきです。Meshでは、これらのユーザニーズに合わせてマルチクラスターサービスメッシュを運用することに関して、質問を受けています。組織規模上の理由から複数のクラスタを運用していますが、それらの監視と管理をひとつの場所で行いたいと思っています。クラスタ間通信は一般的に行いませんが、実施する場合には、明確に定義されたAPIを通じて行っています。高可用性のために複数のクラスタを立ち上げています。それらは相互のクローンで、一方のクラスタに障害が発生した場合に、他方のクラスタがそれを引き継ぎ可能であることが非常に重要です。ハイレベルなアプリを構成するために、複数のクラスタを結合しています。エンドツーエンドのアプリケーションエクスペリエンスを適切に提供するため、クラスタ内のマイクロサービスが、別のクラスタのマイクロサービスと通信する必要があります。3番目のカテゴリは、クラスタ間トラフィックを必要とするマルチクラスタです。クラスタ間トラフィックのサポートが必要な場合は、クラスタ間のネットワーキングや、フォールトトレランスの要件によって実装が異なります。マルチクラスタで何が得られるのかマルチクラスタとサービスメッシュを検討する場合には、まず何が必要なのかを特定し、その上で実現方法に移る必要があります。glass)複数のサービスメッシュ(クラスタ毎にひとつ)を1か所から運用する方法です。glass)に表示することが可能です。domain)サービスメッシュを使用して、強力な相互TLS暗号化で保護されたワークロード識別を提供します。このようなゼロ信頼モデルは、送信元IPのようなトポロジ情報に基づいてワークロードを信頼する方法よりも優れています。脆弱な境界スタックによって出所をコントロールするのではなく、暗号法による証明を基盤としているからです。統合信頼ドメインでは、すべてのワークロードが共通の信頼基盤につながることによって、相互認証を可能にしています。サービスメッシュコントロールプレーンは、それがひとつであるか、あるいは複数であるかに関わらず、共通の信頼基盤に対して設定されます。domain)クラスタとその関連するインフラストラクチャ自体が正常に動作する上で、他のクラスタに依存しないクラスタは、独立障害ドメインです。ここで言う"関連するインフラストラクチャ"の中には、サービスメッシュも含まれています。サービスメッシュをインストールしているならば、通信のレジリエンスをアプリケーションの下にあるインフラストラクチャ層に移すことがその目的だからです。ひとつのクラスタ内のサービスメッシュに障害が発生した場合に、それによって別のクラスタ内のサービスメッシュが損なわれる可能性があるならば、それは独立障害ドメインとは認められません。いったサービスメッシュのメリットをその通信に持たせたいのであれば、クラスタ間トラフィックをサービスメッシュの一環として確保する必要があります。東西のトラフィックがひとつのクラスタから出て、インターネットなど中間ネットワークを経由して、別のクラスタに入る必要があるのです。これはおそらく、ほとんどの人がマルチクラスターサービスメッシュを検討する場合に最初に考えることですが、フォールトトレランスにも影響するので、ここでは個別に説明します。異種(heterogeneous)/非フラット(non-flat)ネットワーク非フラットネットワークは、フラットなネットワークを要件として持つことなく、複数のクラスタにまたがるサービスをサポートします。これはつまり、他のメッシュを考慮せずに、ひとつのメッシュ内のIP割り当てが可能であると同時に、メッシュ間の通信にVPNやネットワークトンネルが必要でないということを意味しています。あなたの組織がすでに多数のさまざまなクラスタを抱えていて、まだポッドのIPアドレス範囲の干渉防止策が取られていないか、あるいは2度と経験したくないような困難を経験しているのならば、これはまさにうってつけのものになるでしょう。マルチクラスタ・サービスメッシュ・アプローチマルチクラスタに何を求めるかはそれぞれ違うかも知れませんので、それぞれのアプローチで何を提供できるのか、順に見て行きたいと思います。独立したクラスタ群これはマルチクラスタではありません。複数のクラスタがあって、それぞれがサービスメッシュを使用しているとしても、統一的なマルチクラスタサービスメッシュを採用しなければならない、ということではないのです。そもそも、なぜ複数のクラスタになったのか、考えてみてください。個々のクラスタを、独立した独自の障害ドメインにしたいのであれば、依存関係を削除して、クラスタを分離するのが合理的です。ニーズさえ満たしているならば、ポッドのスケジューリングや永続化ディスク管理のように、サービスメッシュをクラスタ単位のサービスとして扱うことに何ら問題はありません。独立クラスタ群アプローチの次のステップは、複数のクラスタを対象とする共通管理システムです。このモデルでは、各クラスタは独立して動作しますが、それぞれのメッシュは共通の管理インターフェイスを通じて管理されます。システム(あるいは、このケースではシステム群)の監視やデバッグに使用するものを、システムそれ自体の外部に常駐するようにしておけば、システムが故障した場合でも検査や修正が可能になります。domain)とすることも可能です。障害ドメインの独立性が最優先事項である場合、これはよい選択になります。glass)にすべてを統合することが可能になるため、ソフトウェアをサービスとして使用するのに適しています。Meshでは、クラスタ間のアプローチを有効にしない場合でも、このユースケースをサポートできるようにしています。このアプローチは他のものもサポートしますが、ユーザが不必要にクラスタ間トラフィックに殺到しないように注意してください。ゲートウェイ経由のクラスタ対応サービスルーティングIstioでのこのアプローチには、クラスタ毎にひとつずつの独立したサービスメッシュと、クラスタ内のサービスが他のクラスタ内のサービスと通信可能にするための設定が必要になります。最初に、すべてのメッシュに対してひとつの統合信頼ドメインを設定します。次に、別のクラスタにあるサービスからの信頼できるトラフィックを受け入れるように、入力ゲートウェイを設定します。最後に、特定サービスのトラフィックをひとつのクラスタからルーティングして、別のクラスタに送信できるようにサービスエントリを設定します。異なるクラスタ内のサービスが互いに直接通信できるようにするには、これが最初の方法です。同時に、各クラスタは、依然として独立したメッシュ制御プレーンおよび障害ドメインです。クラスタBのサービスメッシュに障害が発生しても、クラスタAは機能します。クラスタBのサービスが利用できなくなった場合も同様です。このクラスタ間トラフィックを設定するのは、ユーザの責任になります。フラットネットワークこのモデルでは、すべてのクラスタにわたるサービスメッシュについて述べています。各クラスタのポッドが重複しないIPアドレスを持つように調整して、すべてのポッドが任意のクラスタ内の他のポッドにトラフィックをルーティングできるようにします。共通のファイアウォール内に多数のクラスタがあるかも知れませんし、クラスタ間にVPNトンネルを構築する場合もあります。各クラスタから検出されたポッド、サービス、設定をひとつの全体ビューにまとめるように、サービスメッシュを設定します。フラットネットワークでは、すべてのクラスタにまたがった、ひとつのスーパーサービスメッシュが存在するかのように見えます。この方法には、いくつかの欠点があります。このスーパーサービスメッシュは、ひとつのコントロールプレーンによって管理されるため、問題が発生した場合には、すべてのクラスタのサービスメッシュに影響が及ぶのです。複数のKubernetesクラスタへの分割が、元々はフォールトトレランスを目的としたものであった場合、このアプローチは、それを無効にすることになります。ひとつの考慮すべき事項は、すべてのクラスタを管理するようにコントロールプレーンを拡張する必要がある、ということです。このフラットネットワークは、コントロールプレーンとクラスタ間トラフィックを処理するために十分なパフォーマンスを備えていなければなりません。スプリットホライズン・エンドポイントディスカバリサービス(EDS)このアプローチも同じように、クラスタをまたいだひとつのサービスメッシュを生成しますが、フラットなネットワーク構成は必要ありません。スプリットホライズンDNSに相当するIstioのEDSが、フラットネットワークの要件を置き換えます。クラスタ内のポッドのサイドカーには、通信対象となるサービス毎のエンドポイントがリストとして設定されています。同じクラスタ内にあるポッドはEDSリスト内に直接表れますが、別のクラスタにあるポッドに対しては、代わりに他のクラスタの入力ゲートウェイが示されています。ポッドは、通信するエンドポイントを選択してトラフィックを送信します。エンドポイントがローカルの場合、通信はポッドとポッドで直接行われます。リモートエンドポイントを選択した場合は、ポッドが通信しようとしているサービス用にマークされた、関連する入力ゲートウェイのアドレスにトラフィックを送信します。入力ゲートウェイはトラフィックを受け取って、サービスを実装するクラスタ内のポッドのひとつに送信します。Indication(SNI)が使用されます。フラットネットワークのアプローチと同じく、これによって統合されたサービスメッシュコントロールプレーンが形成され、単一の障害ドメインと単一の信頼ドメインが導入されます。ネットワーク構成がフラットである必要はなく、ひとつのクラスタが、他のクラスタの入口ゲートウェイのパブリックアドレスにトラフィックを送信できればよいのです。マルチクラスタにすべきか、そうではないか開発上および組織上の理由から複数のクラスタを運用する場合は、自らの要件を理解した上で、それらをマルチクラスタ環境で接続するかどうかを決定し、そうであれば、さまざまなアプローチと、それぞれの選択肢に関わるトレードオフを理解することが重要です。ここまで読んだのであれば、おそらくは、マルチクラスタを選択するでしょうから、本当の問題は、最良の実装方法は何か、ということになります。以下の表が、あなたにぴったりのアプローチを決める手助けになればと思います。✓サービスメッシュの役割を果たすIstioが有効で、適切に使用されていれば、それがマルチクラスタ通信を容易にしてくれます。複数のクラスタにまたがるコミュニケーションの単純化にサービスメッシュの利用を検討すべき理由と方法、サービスメッシュによるマルチクラスタ通信、あるいはサービスメッシュ全般に関する私の見解について、より詳しい話をしたいのであれば、andrew@aspenmesh.ioまでお気軽にお問い合わせください。MeshのCTOで、組織におけるマイクロサービス管理の負担軽減を支援するためにエンタープライズサービスメッシュを開発しています。Kubernetesのようなコンテナ環境ソフトウェアを扱うネットワークアーキテクトであるJenkins氏は、急速に変化するチームを目に見える成果へと向かわせる、技術的リーダーシップをキャリアとしています。氏の専門分野はC++、JavaScript(Node.js)、Python、C、Go、Javaによるソフトウェア開発です。ソフトウェアおよびハードウェアのテスト、FPGA、および宇宙科学機器のボード設計の経験も持っています。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。