タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
マイクロソフトやHashiCorpらが「Service Mesh Interface」（SMI）を発表。Kubernetes上のサービスメッシュAPIが標準化へ
Kubernetes上で提供されるサービスメッシュのAPIや基本的な機能の標準仕様となる「Service Mesh Interface」（SMI）を、マイクロソフトやHashiCorpらが共同で発表しました。 現在、サービスメッシュを提供するソフトウェアはそれぞれAPIや機能などが異なっているため、サービスメッシュを利用するアプリケーションは、特定のサービスメッシュソフトウェアに依存したものにならざるを得ません。 SMIではサービスメッシュが提供する基本的な機能とAPIが標準として策定されるため、サービスメッシュに対する一定のポータビリティの実現が期待されます。 サービスメッシュとはアプリケーションレベルでの便利機能を提供する Kubernetesは、多数のDockerコンテナをクラスタ化する際の管理機能を提供するオーケストレーションツールとして事実上の標準となりました。 具体的には、コン
原 康紘 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。 AWS の詳細については http://aws.amazon.com/jp
サービスメッシュは、マイクロサービスアーキテクチャの様々な問題点や課題を解決します。Kubernetes クラスターへの導入もそこまで複雑ではなく、サービスメッシュから得られるメリットは計り知れません。 カナダ・バンクーバーオフィスの山口です。 Kubernetes でマイクロサービスのアプリケーション開発をしていると、一度はサービスメッシュという言葉を聞いたことがあるのではないでしょうか。 マイクロサービス間の通信制御において、サービスメッシュは非常に強力な武器となります。しかし、Kubernetes クラスターへサービスメッシュを導入するのは多少敷居が高く、躊躇している方も多いかと思います。 今回はサービスメッシュの概要についてご説明します。そして次回以降で、EKS クラスター上で Istio や App Mesh といった主要なサービスメッシュの導入方法についてお伝えしていきます。
分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要
分散モノリスとWebAssemblyランタイムを用いた新しいアプリプラットフォーム「Wasmer Edge」登場。オーケストレーションもサービスメッシュも不要 WebAssemblyランタイム「Wasmer」の開発元であるWasmer社は、エッジロケーション上のデータセンターにWebAssemblyランタイムを展開し、分散モノリスなアーキテクチャを用いたサーバレス型の新しいアプリケーションプラットフォーム「Wasmer Edge」を発表しました。 The Cloud is dead, long live the Cloud! Announcing Wasmer Edgehttps://t.co/VjGsbMwopy pic.twitter.com/5mTtKBBjsZ — Wasmer (@wasmerio) June 15, 2023 上記のツイートに示されているように、Wasmer E
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
2016年頃「サービスメッシュ」という用語は、マイクロサービス、クラウドコンピューティング、DevOpsの分野に登場しました。楽天的なあるチームは、2016年にこの用語を使用して彼らの製品である Linkerd を説明しました。コンピューティングの多くの概念と同様に、実際には、関連するパターンとテクノロジーの長い歴史があります。 サービスメッシュの登場は、主に IT ランドスケープの最悪の状況によるものでした。開発者は、複数言語 (ポリグロット) アプローチを使用して分散システムの構築を開始し、動的なサービスディスカバリーを必要としていました。運用は一時的なインフラストラクチャの使用を開始し、避けられない通信障害を適切に処理し、ネットワークポリシーを適用したいと考えていました。プラットフォームチームは、Kubernetes などのコンテナオーケストレーションシステムの採用を開始し、Envo
サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve?
サービスメッシュは本当に必要なのか、何を解決するのか / Service meshes - Do we really need them? What problems do they solve? Talked at AWS Summit Tokyo 2019 & Developers Summit 2020. 説明つきの動画にてご覧になりたい方はこちらもどうぞ → https://www.youtube.com/watch?v=ZwfdLAClzsc ※ 2019年の動画のためスライドなど多少中身に違いがありますが、だいたい一緒です
Google、マルチクラウド基盤「Anthos」のAWS正式対応を発表、Azure対応も作業中。サービスメッシュのVM対応も
Google、マルチクラウド基盤「Anthos」のAWS正式対応を発表、Azure対応も作業中。サービスメッシュのVM対応も Googleは、Kubernetesをベースにオンプレミスやマルチクラウドを実現する「Anthos」のAWS正式対応を発表しました。 Build resilient applications & manage them regardless of where they run with these new Anthos features: Multi-cloud support, starting with AWS Bare metal environments (preview) Deeper support for VMs Learn more https://t.co/STG1zcy8HV pic.twitter.com/zMmir3yxLy — Google
このパターンには2つの背景があります。ひとつは、技術者がマイクロサービスアーキテクチャパターンを採用して、複数の(理想的には単一目的で、独立してデプロイ可能な)サービスで構成されるアプリケーションを開発するようになったことです。ふたつめは、企業がコンテナ(Dockerなど)、オーケストレータ(Kubernetesなど)、プロキシ/ゲートウェイ(Envoyなど)といった、クラウドネイティブなプラットフォームテクノロジを支持するようになったことです。 意図 サービスメッシュが解決しようとする問題は次のようなものです。 サービスディスカバリ、ルーティング、アプリケーションレベル(レイヤ7)の非機能通信要件を処理する言語対応の通信ライブラリを、個々のサービス用にコンパイルする必要性の排除 外部サービスのネットワークロケーション、セキュリティ認証、サービス品質(QoS)目標など、サービス通信設定の外
おうちで学ぶサービスメッシュを支える透過型プロキシとしてのEnvoy - NTT Communications Engineers' Blog
この記事は、NTT Communications Advent Calendar 2021 4日目の記事です。 こんにちは、イノベーションセンターでSREとして働いている昔農(@TAR_O_RIN)です。主にNTT Comのソフトウェアライフサイクルの改善への取り組みやアーキテクトに関わる仕事をしております。本日はサービスメッシュを題材に，その中で用いられるEnvoyの活用パターンを手を動かして理解するお話をさせていただきます。 また，昨年までのアドベントカレンダー記事もご興味があればご覧ください！ 2020年 How do you like k3s ? - CoreDNSで作るお家DNS Cacheコンテナ 2019年 TektonでCI/CDパイプラインを手の内化しよう 2018年 DevOpsってこんな仕事！考え方とスキルセットのまとめ 2017年 DockerのnetworkをCa
マイクロサービスの課題を解決する手段の一つとしてサービスメッシュが注目を集めている。だが、注目を集め過ぎるあまり、サービスメッシュを唯一の選択肢と考えてしまうきらいもある。そうした傾向に対し、「サービスメッシュが本当に必要なのかどうかについて、一度原点に立ち返って考えることが重要です」と説くのは、アマゾンウェブサービスジャパン シニアコンテナスペシャリスト ソリューションアーキテクト Hara Tori氏だ。 「Developers Summit 2020」に「サービスメッシュは本当に必要なのか、何を解決するのか」と題して登壇したHara Tori氏は、講演の中で「サービスメッシュはなぜ必要なのか」「何を解決してくれるのか」について、1つのサービスが成長していく姿になぞらえながら解説していった。 そもそも「モノリス」って何だ？ まず、何かのプロダクトやサービスを開発する場合、基本となるのは
Abstruct サービスメッシュが、真に提供する価値は何なのか。それはトラフィック管理と可観測性なのだろうか。 サービスメッシュがこれほどにまで繁栄した理由について、私なりに考察する。 Introduction 近年では、ソフトウェアのアーキテクチャとして、マイクロサービスが大流行した。かつては最大手のインターネット企業のみが必要性に迫られていた、マイクロサービスアーキテクチャだが、昨今の急激に成長するITビジネスの中で、多くの企業にとってマイクロサービスは、あらゆる企業が取り組むべき必然性のあるソリューションとなっている マイクロサービス・アーキテクチャによって、大規模な開発チームがより俊敏になり、より多くのデプロイを実現させられることは、大きなメリットだ。一方で、マイクロサービス特有の課題も数多く存在する。 マイクロサービスに移行する際に発生する運用上の問題の多くは、結局のところ、ネ
サービスメッシュのIstio、機能拡張にWebAssemblyを採用。EnvoyにV8エンジンのWebAssemblyランタイムを統合
サービスメッシュを実現する「Istio 1.5」正式版が登場しました。注目すべき新機能の1つは、Istioの拡張やカスタマイズを行うための統合的な手段としてWebAssemblyが採用されたことです。 Istioが実現するサービスメッシュは、Kubernetes上のさまざまなサービス間のトラフィックの管理やルーティング、ロードバランシング、暗号化通信や認証サービス、モニタリングなどを実現します。 Istioの拡張手段をEnvoy上でのWebAssemblyによる実装で統一へ これまで、Istioの機能を拡張して外部ツールと連係させたり動作をカスタマイズするためには、Mixerプラグインを用いたポリシーやテレメトリのカスタマイズと、Istio内部で使われているプロキシであるEnvoyの拡張機能を利用したデータプレーンのカスタマイズという2つの手段が提供されてきました。 今回正式リリースされた
【レポート】サービスメッシュは本当に必要なのか、何を解決するのか #AWSSummit | DevelopersIO
こんにちわ、札幌のヨシエです。 AWS Summit Tokyo 2019 3日目のA3-03で行われたセッションのレポートを書きましたのでご査収頂ければと思います。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 原 康紘 AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える En
はじめに SRE部 ECプラットフォームSREチームの小林 (@akitok_) です。 ZOZOTOWNでは、マイクロサービス間通信におけるトラフィック制御のために、Istioによるサービスメッシュを導入しています。本記事ではZOZOTOWNのマイクロサービスプラットフォーム基盤（以下、プラットフォーム基盤）において、Istioをいかにプロダクションレディな状態で本番に投入していったか、その取り組みを紹介します。 なお、Istioによるサービスメッシュを導入した背景については、以下の記事で紹介しています。 techblog.zozo.com はじめに What is Istio? Istioをプロダクションレディにするまでに直面した3つの課題 どのようにリソース消費量を見積もるか Data Planeサイジング Envoyプロキシのチューニング 負荷試験 Istioベンチマーク試験 サー
Istioは、サービスメッシュを実現する新たな仕組み「Ambient Mesh」を発表しました。 現在のIstioは、各サービス（≒KubenetesのPod）ごとにプロキシを配置し、サービス間のネットワークをプロキシ経由で構成することによってサービスメッシュを構築しています。これによりサービス間の通信のトラフィックコントロール、暗号化、可観測性（オブザーバビリティ）などの機能が実現されるわけです。 この仕組みは、サービスの隣にプロキシを配置することから、「サイドカー」パターンなどと呼ばれています。 新たな仕組み「Ambient Mesh」では、Pod群をホストしているノードにプロキシを配置し、このプロキシによってサービスメッシュの機能を実現します。 Podごとのプロキシ配置が不要になる、つまり「サイドカーレス」（Sidecar-less）なパターンとなることで、デプロイや管理の容易、コン
マイクロソフト、サービスメッシュの新たなオープンソース実装「Open Service Mesh」発表。Envoy採用、CNCFへ寄贈予定
マイクロソフト、サービスメッシュの新たなオープンソース実装「Open Service Mesh」発表。Envoy採用、CNCFへ寄贈予定 マイクロソフトは、Kubernetes対応のサービスメッシュ（Service Mesh）をオープンソースで実装するプロジェクト「Open Service Mesh」を発表しました。 We are beyond excited to introduce Open Service Mesh (OSM), a lightweight and extensible #servicemesh that implements @SMI_spec and runs on @kubernetesio @EnvoyProxy! Check out what we've been up to here:https://t.co/l6fy4OUorO — Open Servi
はじめに SREの須恵です。 弊社では、昨秋からサービスメッシュの導入を開始していたのですが、なかなかアウトプットできていなかったので書くことにしました。 マイクロサービス化とgRPC 弊社で進行中の技術テーマの1つに「マイクロサービス化」があります。 ビジネスの成長拡大に伴い開発組織も拡大し続けており、どんどん人数が増えています。この増加していく開発者の力を、可能な限り効果的に活かして開発するため、マイクロサービス化に舵を切ることになりました。 （マイクロサービスの動機と目指す結果の詳細はいずれ誰かが記事化することに期待） 今年の1月に弊社初のマイクロサービスとしてリリースされた2つのサービスがあり、それらはgRPCで通信することが決定されていました。また今後も、マイクロサービス間の同期通信にはgRPCの採用が広がる見込みです。 なぜgRPCか モノリスをマイクロサービス化する、あるいは
こんにちは、ご無沙汰しています。 2020 年も終わろうとしていますが、この度サービスメッシュと AWS App Mesh に入門しました。 サービスメッシュ超入門 AWS App Mesh は、AWS 上のサービスでサービスメッシュを実現するための AWS サービスです。 サービスメッシュやその背景については、Tori さんによる「サービスメッシュは本当に必要なのか、何を解決するのか」の講演が詳しいです（この講演にも最後の 5 分くらいで App Mesh が登場します）。 サービスメッシュは、サービス間の通信のリトライ処理、レートリミット、サーキットブレイカーなどの仕組みを、クライアントやサーバー側で制御するのではなく、プロキシサーバーで解決します。 Envoy Proxyは、サービスメッシュのプロキシサーバーとして、広く利用されています。 Envoy Proxy へのリトライやレート
「KubeCon + CloudNativeCon NA 2022」から、サービスメッシュのIstioのセッションを紹介する。IstioはGoogle、IBM、Lyftが初期の開発を行い、その後CiscoやRed Hat、Solo.ioなども加わって開発を継続しているサービスメッシュのオープンソースソフトウェアだ。2022年9月28日にCNCF配下のインキュベーションプロジェクトとして採用された。実は2020年にGoogleはOpen Usage Commonsというトレードマークの管理を行う非営利団体を立ち上げ、Istioを寄贈した。これは「Istioのガバナンスを中立的な組織に移譲して欲しい」というオープンソースコミュニティからは非難されることとなった。GoogleがOpen Usage Commonsを立ち上げたことに関しては以下の記事を参照されたい。 ●参考：GoogleがIsti
LinuxカーネルをフックするeBPFによるサービスメッシュを、Kubernetesに加えてVMやパブリッククラウドまで拡大する「Cilium Mesh」が登場
LinuxカーネルをフックするeBPFによるサービスメッシュを、Kubernetesに加えてVMやパブリッククラウドまで拡大する「Cilium Mesh」が登場 Linuxのカーネルをフックする「eBPF」（extended Berkeley Packet Filter）と呼ばれる仕組みを用いてサービスメッシュを構成する「Cilium」などを開発するIsovalentは、Kubernetesだけでなく仮想マシンやパブリッククラウドまでをカバーするサービスメッシュを実現する「Cilium Mesh」を発表しました。 Introducing Cilium Mesh. Cilium & eBPF powered networking, security, and observability for VMs, servers, and existing networks across cloud,
こんにちは、技術部 SRE グループの ryojiro (@flyhigh_ro) です。今回はクックパッドでのサービスメッシュ基盤を改善した話を紹介します。クックパッドでのサービスメッシュの構成については以前の記事をご覧ください。 クックパッドでは多くのサービス間通信において Envoy を利用していますが、以下のような問題を抱えていました。 改善前の Envoy のバージョンは v1.9.0 (2018/12 リリース) と古く、開発者はそれ以降に実装された機能を利用することが出来なかった。 CDS/RDS を cookpad/itacho によって生成しているため、 v1.9.0 で利用出来る機能であっても cookpad/itacho で実装されていなければその機能を利用できなかった。利用するためには cookpad/itacho にその設定を実装する必要があり、面倒だった。 co
NGINXを有するF5ネットワークスは2020年10月12日、Kubernetes向けサービスメッシュ「NGINX Service Mesh」を発表しました。Kubernetesのサービスメッシュとして有名なIstioの対抗馬が出現した形になります。 Introducing NGINX Service Mesh - NGINX https://www.nginx.com/blog/introducing-nginx-service-mesh/ 複数の小規模なサービスの連携によってアプリケーションを構築するマイクロサービスは、開発スケジュールの短縮や柔軟な拡張性をもたらしましたが、サービス間の通信やデバッグが複雑になるというデメリットもありました。そうした問題を解決するのがサービスメッシュで、NGINX Service Meshではマイクロサービスにおける以下の課題を解決しているとのこと。
サービスメッシュ環境における OpenTelemetry 活用 / OpenTelemetry in Service Mesh
サービスメッシュ環境における OpenTelemetry 活用 / OpenTelemetry in Service Mesh
Ciliumを試す -サービスメッシュにサイドカーが必須だと思っていたがそんなことはなかったぜ- - CADDi Tech Blog
こんにちは。 Platformチームの前多(@kencharos)です。 2022年8月9日に開催した社内勉強会で、eBPFベースのネットワークミドルウェア、Cilium(スリィアム) について発表しました。 この記事は発表の内容をベースに内容を補足したものです。 この記事を読むにあたり、Kubernetesをある程度触ったことがないと用語などが分かりづらいかもしれません。 サービスメッシュやIstioについては、構成や導入目的について簡単に次節に記載しています。 より詳しく知りたい方はIstioのサービスメッシュの説明を見てもらえると、Ciliumとの対比がわかりやすくなるでしょう。 またサービスメッシュを触ったことがある、あるいは運用している方であれば、Ciliumの魅力がより伝わると思います。 eBPFの知識は必要ありません。またeBPFについて同僚も社内勉強会で発表していますので、
独立したサービスを組み合わせて1つのアプリケーションを形作る「マイクロサービスアーキテクチャ」。サービスの構造に合わせて開発組織も個別に独立させることで、機能の追加拡張を容易にしたり、開発スピードの高速化を実現したりできるとして注目されている。 しかし、運用面での課題は少なくない。アプリケーション内でサービス同士が通信するため、アクセス制御やルーティングなどの実装／管理コストは増大する。分割されたサービスそれぞれに独立したソリューションを適用した場合、工数が肥大化したり、仕様や品質がサービスごとに変わったりして、開発スピードに影響を及ぼす恐れがある。 その課題を解決する手段の一つが、サービスの独立性という利点を生かしつつ、運用の一貫性を実現する「サービスメッシュ」と呼ばれるデザインパターンだ。2020年1月に行われた「Envoy Meetup Tokyo #1」の講演で、日立製作所の研究開
Google Cloudで実践！ クラウドネイティブな開発 サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める 本連載は、Google Cloudのアプリ開発とDBプロダクトにおけるスペシャリスト達が、Google Cloudプロダクトを利用した、クラウドネイティブな開発を実践する方法を解説しています。 第6回では、サービスメッシュについて紹介します。 主に対象となる読者は、クラウドを利用してアプリケーションを開発するエンジニア、またはその基盤を構築するエンジニア、サービス開発に携わるプロダクトマネージャーを想定しています。 マイクロサービスアーキテクチャの課題 これまでの連載ではクラウドネイティブなアプリケーションの開発について紹介しました。小さい独立して動作するサービスが連携するマイクロサービスアーキテクチャは、スケーラビリティ、独立した開発の容易さ、
Cloud Native Computing Foundation（CNCF）は、サービスメッシュのIstioが十分成熟した段階に到達したとして、「卒業」（Graduation）プロジェクトになったことを発表しました。 卒業となっても引き続きIstioはCNCF傘下で開発が進められるため、CNCFにおける卒業とは、インキュベーション（育成）段階からの卒業という意味だと言えます。 [NEWS] Cloud Native Computing Foundation Reaffirms #Istio Maturity with Project Graduation Read more: https://t.co/enhd4uT0sG#CNCF #servicemesh #cloudnative #oss pic.twitter.com/A355frCNTO — CNCF (@CloudNative
AWSが“複数VPCをまたぐ“サービスメッシュ”、「Amazon VPC Lattice」を発表、どういうものなのか
Amazon Web Services（AWS）は2022年11月29日（米国時間）、年次イベント「AWS re:Invent 2022」で、複数のAmazon VPC（Virtual Private Cloud）にまたがるサービスレベルのネットワーキングを実現する「Amazon VPC Lattice」を発表した。 VPC Latticeでは、複数のVPC／アカウントに分散するサービス（アプリケーション）間のルーティング、アクセス管理、監視が行える。その意味で「複数VPCをまたぐサービスメッシュ」と表現できる。 VPC Latticeとはどういうサービスか VPC Latticeとは、具体的にはどのようなサービスなのか。 新サービスは集中的なポリシーに基づき、複数VPC／アカウントに分散するコンテナ、仮想／物理インスタンス、AWS Lambda関数のサービス間通信を制御し、モニタリングで
注：この説明の後に、APIゲートウェイを使用するかサービスメッシュを使用するか判断する際にアーキテクトの指針となるチートシートを用意しています。チートシートを先に読みたい方は、「チートシート」セクションに進んでください。 長年にわたり、APIマネジメント（APIM）とAPIゲートウェイは、データセンターの内部と外部の両方で最近のAPIユースケースを実装するために使用されてきた主要テクノロジでした。APIゲートウェイテクノロジは、業界で「フルライフサイクルAPI管理」と呼ばれる、より大きく包括的なユースケースを獲得し、この10年の間に大きく発展しました。このテクノロジは、リクエストのデータプレーンのAPIトラフィックを接続し、安全にして管理するランタイムだけでなく、より広い意味でAPIの作成、テスト、文書化、マネタイズ、モニタリングおよび全体的な公開を可能にする一連の機能であり、最初から最
サービスメッシュを実現する「Istio 1.2」リリース。安定性向上、IPv6の実験的サポート、Datadogへのトレース送信など
サービスメッシュを実現する「Istio 1.2」リリース。安定性向上、IPv6の実験的サポート、Datadogへのトレース送信など サービスメッシュは、クラスタ内の個々のサービスに対してプロキシによる通信の仲介を通じてさまざまな機能を提供します。 例えば、ブルー／グリーンデプロイメントと呼ばれる、あるサービスを新版に切り替える際のトラフィックの動的な切り替えや、サービス間の通信を暗号化し、サービス間での認証をきちんと行うことでセキュリティを高めることも実現してくれます。 さらにプロキシを通じてサービスのモニタリングやログ収集を行うことで、サービスとアプリケーションの稼働状況を把握できるようにもしてくれます。 ビルトやテストなど、リリースのための自動化体制を強化 Istioは2018年8月にバージョン1.0が登場。次のバージョン1.1が登場したのはその7カ月後の2019年3月、そして今回のバ
サービス メッシュは、サービス間の通信を支援する、アプリケーションのインフラストラクチャ レイヤーです。 サービス メッシュは、ワークロードに対するトラフィック管理、回復性、ポリシー、セキュリティ、強力な ID、監視などの機能を提供します。 アプリケーションはこれら運用上の機能から切り離され、サービス メッシュによりアプリケーション レイヤーからインフラストラクチャ レイヤーに移されます。 シナリオ サービス メッシュを使用する場合は、次のようなシナリオを実現できます。 クラスター内のすべてのトラフィックの暗号化: クラスター内の指定されたサービス間で相互 TLS を有効にします。 これは、ネットワーク境界のイングレスとエグレスに拡張でき、アプリケーションのコードとインフラストラクチャを変更せずに、既定で安全なオプションを提供します。 カナリアおよびフェーズ ロールアウト: クラスター内の
サービスメッシュ、Istioがマイクロサービスのトラフィック制御、セキュリティ、可観測性に欠かせない理由
サービスメッシュ、Istioがマイクロサービスのトラフィック制御、セキュリティ、可観測性に欠かせない理由：Cloud Nativeチートシート（9） Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、近年注目を集める「サービスメッシュ」と、そのツールとして人気の高い「Istio」について解説します。
ZOZOテクノロジーズ （現：ZOZO）が進めてきたリプレイスプロジェクトの中で、特に「マイクロサービス化」にフォーカスした内容を担当者が語る「ZOZO Technologies Meetup～マイクロサービス化に取り組む、16年目のZOZOTOWN～ 」。ここで、SRE部の髙塚氏が登壇。ZOZOTOWNが過去に対応してきた課題と、16年目の悩みと解決法を紹介します。 自己紹介と本日の概要・目次 髙塚大暉氏：こんばんは。「ZOZOTOWN（16歳）の悩みをSREが赤裸々に語る」というタイトルで発表します。私は、ECプラットフォームSREチームの髙塚です。AWSとKubernetesでマイクロサービス基盤の構築・運用に従事しています。 本日の概要と目次です。今年で16年目のZOZOTOWNは、思い出だけでなく、技術的な課題もたくさん抱えています。今日はまず、昔からの悩みを説明して、次にアーキ
「サービスメッシュ戦争」も、クラウドネイティブな世界のダイナミズムとCNCF：KubeCon＋CloudNativeCon Europe 2019詳報（2）（1/2 ページ） 2019年5月20～23日にスペイン・バルセロナで開催された「KubeCon＋CloudNativeCon Europe 2019」では、クラウドネイティブな世界のダイナミズムを感じさせる動きが相次いだ。本記事では、OpenTracingとOpenCensusの統合によるOpenTelemetryの発足、およびMicrosoftなどによるService Mesh Interfaceの発表を取り上げ、CNCFのCOO（最高執行責任者）／CTO（最高技術責任者）であるクリス・アニズィック氏のコメントを交えてお届けする。 2019年5月20～23日にスペイン・バルセロナで開催された「KubeCon＋CloudNativeC
特定のビジネスユースケースで組織内のさまざまなエンティティと対話する必要がある場合、これらすべてのエンティティを統合して複合機能を作成するのがESBの仕事でした。 したがって、ESBソリューションは通常、異種のシステムやAPIへのコネクタ、メッセージのルーティング、変換、回復力のある通信、永続性、トランザクションなど、すべての組み込み統合機能の原動力です。 [画像をクリックすると拡大します] 図1: 統合のためのESBの使用 ただし、マイクロサービスアーキテクチャでは、ESBをスマートエンドポイントとダムパイプの構築に置き換えます。つまり、マイクロサービスはすべてのアプリケーション統合を考慮する必要があります。 スマートESBの分散化による明らかなトレードオフは、サービスのビジネスロジックに加えてこれらのアプリケーション統合に対応する必要があるため、マイクロサービスのコードの複雑さが劇的に
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 20 日目の記事です。 皆さん、こんにちは。Google Cloud の内間(@kuchima)です。本日も前日の Kozzy さん(Kozzy Hasebe)に引き続きみんな大好きサービスメッシュネタです。 この記事では、Google Cloud が提供している Traffic Director というサービスを利用したプロキシレス サービスメッシュ（以降、プロキシレス gRPC と記載します) の概要について説明していきたいと思います。 サービスメッシュとは？という話についてはこちらの記事では触れないので、Kozzy さんの記事「Anthos Service Mesh を導入、移行、そして使いこなしてみよう」をご参照ください。 Traffic Direct
Traffic Director と gRPC - サービス メッシュ用プロキシレス サービス | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 7 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。 多くの組織がサービス メッシュを利用しています。それは特にマイクロサービスを多用する環境において、面倒で複雑なネットワーキングの問題が解決されるからです。また、サービス メッシュを利用することで、負荷分散ポリシーやトラフィック マネジメント ポリシーなどのアプリケーション ネットワーキング ポリシーを一元化して管理できます。ただし、サービス メッシュの導入とは従来、（1）インフラストラクチャの管理（コントロール プレーン）、および（2）アプリケーションに代わってネットワーキングを処理するサイドカー プロキシの実行（データプレーン）を意味していました。 Traffic Director は、Google Cloud が管理するコントロール プレーンで、前述したサービス メ
はじめに こんにちは、SRE部 ECプラットフォーム基盤SREブロックの亀井です。 ZOZOTOWNのマイクロサービスプラットフォーム基盤（以下、プラットフォーム基盤）ではサービス間通信におけるトラフィック制御・カナリアリリース実装のため、Istioによるサービスメッシュを導入しました。現在は初期段階としてBFF機能を司るZOZO Aggregation APIとその通信先サービス間へ部分的に導入しています。 ZOZO Aggregation APIについては、以前に三神が紹介しているので、そちらの記事をご参照ください。 techblog.zozo.com その後、Istioによる一貫したトラフィック制御・カナリアリリース実装を目的とし、プラットフォーム基盤全体へサービスメッシュを拡大しました。本記事ではその取り組みを紹介します。 なお、本記事はプロダクション運用中サービスのサービスメッシ
2019年7月6日、株式会社サイバーエージェントが主催するイベント「Battle Conference U30」が開催されました。30歳以下のエンジニアによる30歳以下のエンジニアのための技術カンファレンスである本イベントには、さまざまな領域で活躍する若手が登壇。企業の枠を超えて、自身の技術・事業・キャリアに関する知見を発表しました。「サービスメッシュを導入してよかった話 」に登壇したのは、株式会社サイバーエージェント・江頭宏亮氏。 サービスメッシュ導入の経緯 江頭宏亮氏：ご紹介ありがとうございます。「サービスメッシュを導入してよかった話」というタイトルでお話させていただきます。よろしくお願いします。 まず軽く自己紹介をさせてください。2018年4月にサイバーエージェントに入社して、今はCATS（Client Advanced Technology Studio）という組織に所属しています
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[Kubernetes / Istio] Kialiでサービスメッシュのトラフィックを俯瞰する - zaki work log](https://cdn-ak-scissors.b.st-hatena.com/image/square/21d0a02b121f763f073e039a0a2ba5409df7efc7/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fz%2Fzaki-hmkc%2F20200818%2F20200818213414.png)
サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019
サービスメッシュについて理解する | DevelopersIO
サービスメッシュを完全に理解する / Perfect Service Mesh
サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
そのモノリス、本当にマイクロサービス化が必要？ サービスメッシュも？
サービスメッシュの本質は、トラフィック管理や可観測性ではない
Istioによるサービスメッシュをどのようにプロダクションレディにするか - ZOZO TECH BLOG
Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現
サービスメッシュとしてLinkerdを導入するに至った経緯 - ANDPAD Tech Blog
サービスメッシュとAWS App Meshに入門した | Folioscope
「KubeCon NA 2022」から、サイドカーレスを実装したサービスメッシュのIstioのセッションを紹介
クックパッドのサービスメッシュ基盤を改善した話 - クックパッド開発者ブログ
NGINXがKubernetes向けサービスメッシュ「NGINX Service Mesh」を発表
マイクロサービスを支える「Istio」の実力は？ サービスメッシュの利点と課題
サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp
サービスメッシュのIstio、十分に成熟した段階に到達したとしてCNCFの卒業プロジェクトに
APIゲートウェイとサービスメッシュの違い | gihyo.jp
サービス メッシュについて - Azure Kubernetes Service
モノリスからマイクロサービス化してきたZOZOTOWN 16年目の新たな悩みはサービスメッシュで解決する
「サービスメッシュ戦争」も、クラウドネイティブな世界のダイナミズムとCNCF
マイクロサービスアーキテクチャのためのアプリケーション統合：サービスメッシュはESBではない
Traffic Director でプロキシレス サービスメッシュを試してみる
ZOZOTOWNにおける段階的なIstioサービスメッシュ化戦略 - ZOZO TECH BLOG
サービスメッシュを導入してよかった話
news.yahoo.co.jp
www.cnn.co.jp
www.cnn.co.jp
dengekibunko.jp
mikasako.com
www.gadget2ch.com