Gleyzer両氏によって共同開発されました。2019で、同言語の発表を行いました。InfoQはPurdy氏に言語と、氏らが解決を目指した問題について聞きました。設計/アーキテクチャアジャイルマニュフェスト:ソフトウェアアーキテクトの視点ソフトウェアアーキテクトの役割と責任はアジャイルソフトウェア開発のためのマニフェストの価値と矛盾していると見えますが、優れたアーキテクトはアジャイル開発チームをサポートするテクニックを見つけています。Streamingは、ストリーミングデータのためのSQLライクなインターフェースを提供します。Streamsによって、Redisがストリーミングデータを複数のプロデューサとコンシューマの間で消費、保持、配信することができるようになります。ソフトウェア開発のマニフェストたゆまず息もつかずに市場に突進することで、会社を静かに消滅の崖っぷちへと追い込みます。それは設計してコードを書く方法を再考する時です。簡単さへの投資は、速さへの投資です。簡単さは知的財産の主鉱脈でもあります。競争上の優位性は、一度失ったら、もう一度手に入れることはほとんど不可能です。Buytaerts氏が過去10年間にわたって、企業がDevOps採用のハイプサイクルをくぐり抜け、変革に対する誤解を解消する過程を支援してきた経験について語ります。_原文(投稿日:2019/05/03)へのリンクソフトウェアシステムを最新化する場合の大きな目標のひとつは、その動作の基礎になっているインフラストラクチャから、アプリケーションを切り離すことです。これには多くの利点があります。ワークロードを移行して、クラウドMLや"ビッグデータ"サービスを利用する。リソースのより効率的な割り当てや、アプリケーションのコロケーションによるコスト削減。適切な抽象化を導入し、コンポーネントのより効率的なアップグレードとパッチ適用を行うことによるセキュリティの向上。コンテナや、Kubernetesのようなオーケストレーションフレームワークを使用すれば、基盤となるハードウェアから、アプリケーションのデプロイと実行を切り離すことが可能になります。すべてのアプリケーションがこの種のプラットフォームに移行できるわけではありません。可能であっても、段階的なプロセスで実施したいと考えるのが当然です。このため、トラフィックルーティングをネットワーキングインフラストラクチャから切り離す、さらなる抽象化層が必要になります。このような抽象化は、エッジでは入力ゲートウェイまたはAPIゲートウェイを介して、データセンター内ではサービスメッシュを介して、それぞれ実現されます。私たちDatawireは、過去数ヶ月間、HashiCorpチームの緊密な協力のもとで開発を続けてきました。APIゲートウェイとConsulサービスメッシュ間のインテグレーションをリリースしました。これら2つのテクノロジを組み合わせることにより、アプリケーションのトラフィックルーティングを、基盤となるデプロイメントやネットワークインフラストラクチャから完全に切り離すことができます。Proxyの機能を利用することで、これら2つのテクノロジは、エッジからの動的ルーティングと、ベアメタル、VM、Kubernetesにまたがるサービス間サービスとを提供します。今回のインテグレーションによって、エンドツーエンドのTLSも可能になり、その他の部門横断的な要件のサポートもできるようになります。関連スポンサーコンテンツ多くの組織が、大規模なデジタル変革活動の一環として、"アプリケーションの最新化(modernisation)"プログラムに取り組んでいます。この目標は極めて大きなものですが、一般的には機能のモジュール化、クラウドMLやビッグデータサービスとの統合、セキュリティの向上、コストの削減、インフラストラクチャレベルでの可観測性(observability)および回復性(resilience)に関する機能の実現などを通じたイノベーション能力の向上に焦点が当てられています。作業に対する"DevOps"あるいは責任共有アプローチの適用などの活動を伴います。アプリケーションの最新化における重要な技術的目標のひとつは、基盤となるインフラストラクチャからアプリケーション、サービス、機能を切り離すことです。これに関して、いくつかのアプローチが、クラウドベンダによって進められています。Outpostsは、AWSによって完全に管理されているカスタムハードウェアのインストールを通じて、AWSのサービスと運用モデルを、ユーザの所有する既存のデータセンタに提供するものです。Stackは、Azureクラウドとユーザ自身のオンプレミスハードウェアにわたるハイブリッドアプリケーションを、一貫して構築および実行できるようにする、Azureサービスの拡張機能です。Anthosは、ソフトウェアベースの抽象化層と、関連するコントロールプレーンを通じて、GCPのコアサービスをユーザのインフラストラクチャや他社クラウドに拡張できるようにします。その他にもAmbassador、Consul、Istio、Linkerdといったプロジェクトが、既存のコンテナベースの抽象化層によってクラウドに依存しないデプロイメントを実現するとともに、アプリケーションとインフラストラクチャの分離を可能にするための、ネットワークを抽象化する層を提供しようとしています。Dockerはデプロイメントユニットとしてのコンテナ利用を一般的なものにしました、そしてGoogleは、アプリケーションの大半がコンテナの集合体としてデプロイされることを認識し、それをKubernetesの中で"Pod"と名付けたのです。ここでのコンテナは、ネットワークとファイルシステムの名前空間を共有しています。ロギングやメトリック収集を提供するユーティリティコンテナは、アプリケーションと組み合わせることが可能です。Pod内に展開されたビジネスファンクションは、名前とネットワークのエンドポイントを提供する"サービス"抽象化を経由して公開されます。この抽象化を使用することで、デプロイとリリースの分離が可能になるのです。複数バージョンのサービスをいつでもデプロイできると同時に、トラフィックをバックエンドのPodに("シャドウイング"トラフィック、"カナリアリリース"というように)選択的にルーティングすることで、機能をテストしたり、あるいはリリースしたりすることができます。この動的ルーティングは通常、エッジ("エッジプロキシ"または"APIゲートウェイ")とサービス相互間("サービスメッシュ"と総称されるサービス間プロキシ)の両方で、プロキシを介して実現されます。多くの組織にとって、最大の課題のひとつは、エンドユーザや社内の開発チームおよび運用チームを混乱させることなく、このようなアプリケーションとインフラストラクチャの分離を実現することにあります。この問題はメインフレームやベアメタル、VM、コンテナ、COTS、サードパーティ製アプリケーション、SaaS、社内マイクロサービスなど、一般的な企業のIT分野におけるインフラストラクチャとアプリケーションの多様性に起因しています。従って、Kubernetesやクラウドサービスのような新しいインフラストラクチャに向けて、レガシアプリケーションの漸進的な最新化と移行を可能にする、明確な道筋を確立することが大きな目標になります。Proxyは現在、インフラストラクチャの世界を席巻していますが、それには正当な理由があります。このプロキシは"クラウドネイティブ"およびレイヤ7(アプリケーション)プロトコルを中心とする時代に生まれました。そのため、最新インフラストラクチャと関連する開発者/オペレータのユースケースを極めて効率的かつ効果的に処理するのです。Lyft、eBay、Pinterest、Yelp、Grouponといったエンドユーザ企業が、すべての主要クラウドベンダとの組み合わせで、サービスディスカバリ、ルーティング、可観測性を実装するために、エッジでEnvoyを運用しています。重要なのは、彼らが多くの場合、旧世代のメインフレームやVMベースのアプリケーションと、より近代的なコンテナベースのサービスとを橋渡しする通信手段としてEnvoyを使用していることです。データプレーン(ネットワークプロキシ実装自体)は非常に強力ですが、プロキシの設定および監視に使用されるコントロールプレーンには、急勾配の学習曲線が存在します。そこで、Envoyを使用する開発者エクスペリエンスを簡素化する目的で、新たなオープンソースプロジェクトが出現しました。APIゲートウェイはEnvoy上で動作するエッジプロキシで、入力ないし"南北"トラフィックの管理に使用することにより、Envoyの設定を簡素化するコントロールプレーンを提供します。HashiCorpのConsulサービスメッシュは、サービス間通信ないし"東西"トラフィック用のコントロールプレーンで、プラグイン可能なプロキシ構成のひとつとしてEnvoyをサポートしています。これら2つのテクノロジを使用することの大きなメリットは、外部ユーザと内部ユーザ、両方との接続を保ったまま、アプリケーションの任意の場所での実行が可能になることです。Gatewayは、アプリケーションの構成と場所を外部コンシューマから切り離します。アプリケーションがどこにデプロイされているかに関係なく、エンドユーザ、モバイルアプリ、サードパーティからの外部要求を動的にルーティングします。サービスメッシュは、ロケーションの透明性を提供することによって、アプリケーションを内部コンシューマから切り離します。アプリケーションがどこにデプロイされているかに関係なく、内部サービス間要求を動的にルーティングします。VM、コンテナ、その他へのルーティングConsulの一般的なデプロイメントは、複数のConsulサーバ(高可用性を提供するため)と、各ノード上のConsulエージェントで構成されています。ここでConsulは、データセンタ全体の設定の"真実の源"として機能し、利用可能なサービスと設定、エンドポイントを追跡し、TLS暗号化のための秘密鍵を保存します。サービスディスカバリにConsulを使用することで、Ambassadorは、ベアメタル、VM、Kubernetesのいずれで実行しているかにかかわらず、ユーザ側のエンドポイントまたはRESTに似たAPIから、Jデータセンター内の任意のConsulサービスにルーティングできます。Consulはまた、Envoyプロキシを通じて、サービス間トラフィックを透過的にルーティングすることもできます(サービス"サイドカー"パターンを使用)。これにより、エンドツーエンドのトラフィックをTLSで完全に保護することができます。Ambassadorは、アプリケーションやサービスへの共通の入り口として機能し、ユーザ認証、レート制限、API管理、TLSの切断など、南北トラフィックの分野横断的な機能を提供します。Consulはサービスメッシュとして機能し、ロケーションの透明性を提供するためのサービス名定義に加え、ネットワークの"セグメント化"など、明確かつ分野横断的なセキュリティ問題を宣言的に指定するポリシ・アズ・ア・コードを実現しています。新たなアプローチとなります。サービス名を使用したアクセスポリシの定義により、複雑なホストベースセキュリティグループやネットワークアクセスリストは回避されています。導入方法Ambassadorでは、Kubernetesアノテーションに基づいて構築された宣言型設定フォーマットを使用します。サービスディスカバリにConsulを使うためには、最初に、Kubernetesサービス内のアノテーションを通して、Consulをリゾルバとして登録します。dc3Ambassadorでは、標準のアノテーションベースの設定フォーマットを使用した、任意のサービスへのルーティングの設定が可能になりました。gRPC、タイムアウト、設定可能なロードバランシングなど、Ambassadorのすべての機能が完全にサポートされています。/foo/と、Consulに登録されているfooサービス("foo-proxy")のマッピングを示しています。オプションのtlsプロパティでは、AmbassadorがConsulサービスのプロキシと通信するために使用するTLSコンテキストを定義することができます。API経由で、TLS証明書を自動的に同期します。すべてのトラフィックが安全であることを保証するためには、ローカルネットワークアドレスにバインドするようにKuberntesPod内のサービスを設定する、あるいは、プロキシがリスンしているポートを経由したインバウンド通信のみを受け入れるように基盤となるVMを設定するなどの方法で、サービスそのものを、Consulサービスプロキシからのトラフィックのみ受信するように設定する必要があります。データセンタ全体へのAmbassadorとConsulのロールアウトには、他にもいくつかのメリットがあります。最新のプロトコルであるHTTP/2やgRPCなどの適切なロードバランスが可能になります。(レイヤ4ロードバランサを使用しない理由について詳しく議論するのは、このユースケースでは適切ではありません。Geckoboard"という優れた記事を参照してください。)Consulはさらに、エントリの監視、分散ロック、ヘルスチェックなどを含むキーバリューストアや、初期状態での複数データセンタサポートといった、分散システム構築時に有用な追加プリミティブも提供します。関連技術IBM、Googleなど、いくつかの組織や個人が、サービス間通信を中心に、Envoyにための簡略化されたコントロールプレーン提供を目的としたIstioプロジェクトを設立しました。このプロジェクトには後に、進捗管理のための"ゲートウェイ"の概念が追加されています。現在Istioは、Kubernetesへのデプロイメントのみをサポートしていますが、その他のプラットフォームのサポートもロードマップ上にあります。BuoyantはLinkerdサービスメッシュを開発しました。東西トラフィックの管理が主な対象ですが、一般的な南北プロキシとのインテグレーションも提供しています。APIゲートウェイチームも、NGINXを使用した初期段階のサービスメッシュソリューションを開発中です。サービスメッシュの"ビッグバン"型ロールアウトに注意せよ私はDatawireでの仕事を通じて、組織全体でサービスメッシュの展開に取り組んでいるいくつかの組織と話をしました。クラウド導入やソフトウェア定義型ネットワーク(SDN)が採用されても、比較的集中されたまま残っているネットワーク運用が、ソフトウェアデリバリにおける最後の要点のひとつであることには、疑問の余地がありません。これは時として、あらゆるネットワーク技術は集中管理されるべきである、という考えにつながります。一般論として、サービスメッシュをデプロイする場合には、この種のアプローチはうまくいきません。大企業内のすべてのエンジニアが、すべてのアプリケーションをまとめてメッシュに移行する作業をオーケストレーションするというのは、合理的ではないのです。段階的な導入アプローチの方が、より現実的ですし、エッジではそうあるべきだと思います。外部公開しているアプリケーションや製品の構成とリリースを分散化できれば、さらには最新のプロキシが提供する機能を活用する方法を学ぶことができれば、内部サービスのサービスメッシュを段階的に展開する上で、理想的な出発点になります。サービスメッシュのロールアウトにおける最初のイテレーションでは、ルーティングに注目するのが一般的です。前項のAmbassadorとConsulの設定で説明したように、最新のエッジプロキシを設定したのならば、どこに、あるいはどのように、デプロイされているかに関わらず、トラフィックルーティングの既存Consul登録サービスへの選択的な移行が可能になります。ルーティングが完了すれば、個々のサービスに対してConsulプロキシを段階的に追加して、エッジから各サービスエンドポイントに、トラフィックを(TLSを使用して)安全にルーティングできます。TLSを実装したサービスと、データセンター内のプレーンテキストを混在させても、まったく問題ありません。目標は通常、すべてのトラフィックを保護することであり、AmbassadorとConsulの組み合わせを使用することで、エンドユーザからサービスへのトラフィックの、エンドツーエンドの暗号化を段階的に展開することが可能になります。まとめ今回の記事では、アプリケーション最新化プログラムの一環として、アプリケーションをインフラストラクチャから切り離すことの意義について論じてきました。これらのアプリケーションがどこにデプロイされているかに関わらず、APIゲートウェイとサービスメッシュを統合してデプロイすることにより、エンドユーザからのトラフィックを新規および既存サービスの両方にルーティングするようなインクリメンタルなパスを提供できる、という方法について解説しました。アプリケーションが新プラットフォームに移行した場合でも、エッジからサービス、あるいはサービス間でのトラフィックのルーティングに使用するIDは変わりません。今回のゲートウェイからメッシュへというソリューションを実装することには、エンドツーエンドのトラフィックの暗号化、アプリケーションレベルのネットワーキングメトリクスに対する可観測性の向上など、グローバルおよびサービス間を問わず、他にもいくつかのメリットがあります。AmbassadorとConsulの統合に関する詳細は、Ambassadorのドキュメントに、チュートリアルはConsulのドキュメントにあります。Datawireの独立系技術コンサルタントおよびプロダクトアーキテクトとして活動しています。氏の技術的専門知識は、「DevOps」ツーリング、クラウド/コンテナープラットフォーム、マイクロサービス実装を中心としたものです。氏は、Javaチャンピオンであり、いくつかのオープンソースプロジェクトにもコントリビュートすると同時に、InfoQ、O'Reilly、TheNewStackでの記事の執筆や、OSCON、QCon、JavaOneなどの国際会議での講演を常に行っています。氏は恵まれた自由時間の中で、走り、読書し、また旅を楽しんでいます。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見るあなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。登録するとさまざまなことができます。アカウント登録をしてInfoQをお楽しみください。あなたの意見をお聞かせください。毎週火曜日に前週のまとめコンテンツがお送りいたします。25万人ものシニアデベロッパーのコミュニティーにぜひご参加ください。サンプルを見る様々なイノベーターとアーリーアダプターがお送りするテクノロジーの概要を見る。自分がまだ知らないことに気づいていないと知るあなたが興味のあるトピックスをいつでも最新な情報に。あなたのメールアドレスはこちら国を選んでください。プライバシーポリシーに従って私の個人情報を扱うことに同意します。よい世界へ私たちが暮らす世界を大切に思い、よりよいものにしたいと考えています。人のためのソフトウェア開発を加速し私たちのミッションを実現することで、この思いを成し遂げようとしています。私たちは利益の1%をさまざまな慈善団体に寄付しています。会社として、また従業員として、そうしたことの価値を強く信じているからです。with.プライバシーBTあなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。アドレス*Eメールを変更すると確認のメールが配信されます。会社名:現在の会社名をご入力ください。Other組織規模:現在の組織規模をご入力ください。2,501+国:現在の国を設定してください。Zimbabwe都道府県:現在の都道府県に設定してください。次の都道府県にアップデートする:ニュースレターを購読しますか?インダストリーメールを購読しますか?本Eメールに登録すると、以前より関心のあったトピックの関連情報をお送りする場合がございます。詳細はこちらのプライバシーポリシーをご覧ください。newsletter?新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。