タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
サービスメッシュは、マイクロサービスアーキテクチャの様々な問題点や課題を解決します。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?
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
Abstruct サービスメッシュが、真に提供する価値は何なのか。それはトラフィック管理と可観測性なのだろうか。 サービスメッシュがこれほどにまで繁栄した理由について、私なりに考察する。 Introduction 近年では、ソフトウェアのアーキテクチャとして、マイクロサービスが大流行した。かつては最大手のインターネット企業のみが必要性に迫られていた、マイクロサービスアーキテクチャだが、昨今の急激に成長するITビジネスの中で、多くの企業にとってマイクロサービスは、あらゆる企業が取り組むべき必然性のあるソリューションとなっている マイクロサービス・アーキテクチャによって、大規模な開発チームがより俊敏になり、より多くのデプロイを実現させられることは、大きなメリットだ。一方で、マイクロサービス特有の課題も数多く存在する。 マイクロサービスに移行する際に発生する運用上の問題の多くは、結局のところ、ネ
マイクロサービスの課題を解決する手段の一つとしてサービスメッシュが注目を集めている。だが、注目を集め過ぎるあまり、サービスメッシュを唯一の選択肢と考えてしまうきらいもある。そうした傾向に対し、「サービスメッシュが本当に必要なのかどうかについて、一度原点に立ち返って考えることが重要です」と説くのは、アマゾンウェブサービスジャパン シニアコンテナスペシャリスト ソリューションアーキテクト Hara Tori氏だ。 「Developers Summit 2020」に「サービスメッシュは本当に必要なのか、何を解決するのか」と題して登壇したHara Tori氏は、講演の中で「サービスメッシュはなぜ必要なのか」「何を解決してくれるのか」について、1つのサービスが成長していく姿になぞらえながら解説していった。 そもそも「モノリス」って何だ？ まず、何かのプロダクトやサービスを開発する場合、基本となるのは
サービスメッシュのIstio、機能拡張にWebAssemblyを採用。EnvoyにV8エンジンのWebAssemblyランタイムを統合
サービスメッシュを実現する「Istio 1.5」正式版が登場しました。注目すべき新機能の1つは、Istioの拡張やカスタマイズを行うための統合的な手段としてWebAssemblyが採用されたことです。 Istioが実現するサービスメッシュは、Kubernetes上のさまざまなサービス間のトラフィックの管理やルーティング、ロードバランシング、暗号化通信や認証サービス、モニタリングなどを実現します。 Istioの拡張手段をEnvoy上でのWebAssemblyによる実装で統一へ これまで、Istioの機能を拡張して外部ツールと連係させたり動作をカスタマイズするためには、Mixerプラグインを用いたポリシーやテレメトリのカスタマイズと、Istio内部で使われているプロキシであるEnvoyの拡張機能を利用したデータプレーンのカスタマイズという2つの手段が提供されてきました。 今回正式リリースされた
はじめに 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 へのリトライやレート
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,
「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
こんにちは、技術部 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について同僚も社内勉強会で発表していますので、
Cloud Run のサービスメッシュを試した 以前から GKE では Cloud Service Mesh を使ってサービスメッシュを利用することができましたが、Cloud Run でもサービスメッシュを利用できるようになりました（作成時点の2024-09-02ではプレビュー段階）。 この記事ではサービスメッシュならではの機能をサンプルアプリを使って確認します。 検証シナリオ 検証環境の構成 サンプルアプリとして Istio のドキュメントに掲載されている bookinfo （本の情報やレビューが見られる Web アプリで、マイクロサービスで実装されている）のコンテナイメージを利用します。 検証する機能 下記の4点について確認を行います。 サービス間の認証、認可を自動的に行う 従来の Cloud Run では ID トークンを明示的にヘッダに付与してリクエストを送信する必要があり、アプリ
独立したサービスを組み合わせて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の作成、テスト、文書化、マネタイズ、モニタリングおよび全体的な公開を可能にする一連の機能であり、最初から最
サービス メッシュは、サービス間の通信を支援する、アプリケーションのインフラストラクチャ レイヤーです。 サービス メッシュは、ワークロードに対するトラフィック管理、回復性、ポリシー、セキュリティ、強力な 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は、思い出だけでなく、技術的な課題もたくさん抱えています。今日はまず、昔からの悩みを説明して、次にアーキ
この記事は 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による一貫したトラフィック制御・カナリアリリース実装を目的とし、プラットフォーム基盤全体へサービスメッシュを拡大しました。本記事ではその取り組みを紹介します。 なお、本記事はプロダクション運用中サービスのサービスメッシ
サービスメッシュのIstio、Cloud Native Computing Foundationへの提出を発表 GoogleとIstioの開発チームは、IstioをCloud Native Computing Foundation（CNCF）のインキュベーションプロジェクトに提出することを発表しました。 Great news! With the support of @googleOSS and the Istio Steering Committee, we have applied to become a @CloudNativeFdn project! Take a look at our blog and learn more about this process: https://t.co/2rn2YMKEpl #CNCF pic.twitter.com/SHw677mYE4 —
サービスメッシュはマイクロサービスアーキテクチャを前提とし、アプリケーション間で通信を制御する仕組みを提供します。この制御された通信はメッシュの様に編みがけになっているため、信頼性を向上します。 例として2台構成のホストの場合、通常のアクセスパスは以下になります。 ブラウザでロードバランサーのDNS名にアクセスすると、HTTPリクエストを受け付けたロードバランサーは、ラウンドロビンでバックエンドであるホストの公開ポートにHTTPリクエストを振り分けます。 例えば、片方のホストで何らかの障害が発生し、コンテナがダウンした場合でも以下の経路により、サービスを継続することができます。 要約すると、単純にホストレベルでアプリケーションを分ける構成の場合は、片方のホストに何らかの障害が発生したときにサービスの提供ができなくなります。よって、コンテナ技術を活用し、サービスメッシュにすることで単一障害点
GCP連載#2 Istio on GKEではじめるサービスメッシュ | フューチャー技術ブログ
はじめにこんにちは、TIGの村田です。GCP連載企画2日目の記事です！ 皆さんは普段どのようなアプリケーションを開発されてますか？ 私は最近Kubernetes上にデプロイされるマイクロサービスなアプリケーションに携わっています。 今回はIstio on GKEに焦点をあててGCPにおけるサービスメッシュの活用方法をご紹介したいと思います。 GKEクラスタを作成するまずはクラスタを作成します。 基本的にはデフォルト値のままクラスタ作成してしまおうと思います。 変えるのは一箇所だけ、今回の目玉の部分です。 Additional features の Enable Istio にチェック！ チェックを入れると Enable mTLS 欄が登場します。 選べるのは Permissive と Strict の2種類ですが、今回はデフォルト値である Permissive のままとします。詳しくは以下
サービスメッシュ Istioとは? - Qiita
はじめに Kubernetesを利用する時にサービスメッシュを検討することがあるかと思います。 本記事ではサービスメッシュとは何か? また、サービスメッシュの機能を持つIstioについて説明していきます。 サービスメッシュとは サービスメッシュとはマイクロサービスの各サービス間通信を専用のソフトウェアに仲介させることで、マイクロサービス特有の課題を解決する仕組みです。 サービス間通信の運用の課題として以下の項目が挙げられます。 通信の回復性 負荷分散 分散トレース サービスバージョン管理 サービス間トラフィック暗号化 サービスメッシュはこれらの課題に対する有効な対処方法の一つです。 また、上記の項目は各アプリケーションの個別に実装することもできますが、大きなコストがかかってしまいます。 マイクロサービスアーキテクチャではマイクロサービスごとに使用するプログラミング言語やデータベースが異なる
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
2020年におけるIstioサービスメッシュの現状 訳注: この記事は、CNCFのブログポストを日本語に翻訳したものです。 この記事はAlcideのテクニカルマーケティングエンジニア Alon Bergerによって作成されました。 2017年以降、Kubernetesは急成長し、クラウドネイティブコンピューティングのコミュニティ内で重要な役割を果たしてきました。この動きによってマイクロサービスを採用する企業はますます増え、サービス間通信を管理するために専用のソフトウェアが必要であることが認知されるようになりました。 サービスメッシュと、その有力なコントロールプレーンマネージャーの候補であるIstioに入門しましょう。IstioはEnvoyプロキシを中心に構築されたプラットフォームであり、トラフィックの流れを管理、制御、監視し、サービス間の相互接続を保護します。 2019年にCNCFが行った
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)
サービスメッシュについて理解する | DevelopersIO
サービスメッシュを完全に理解する / Perfect Service Mesh
サービスメッシュ必読ガイド - 第2版: 次世代のマイクロサービス開発
![DeNA ネットワーク運用監視ツールの紹介 [DeNA インフラ SRE] | BLOG - DeNA Engineering](https://cdn-ak-scissors.b.st-hatena.com/image/square/1b9acf5c47daa7b9d974947691fc12da8b40f44f/height=288;version=1;width=512/https%3A%2F%2Fengineering.dena.com%2Fblog%2F2024%2F10%2Fdena-network-monitoring%2Fcover.png)
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
サービスメッシュの本質は、トラフィック管理や可観測性ではない
そのモノリス、本当にマイクロサービス化が必要？ サービスメッシュも？
Istioによるサービスメッシュをどのようにプロダクションレディにするか - ZOZO TECH BLOG
Istioが新たな仕組み「Ambient Mesh」を発表。サイドカーなしでサービスメッシュを実現
サービスメッシュとしてLinkerdを導入するに至った経緯 - ANDPAD Tech Blog
サービスメッシュとAWS App Meshに入門した | Folioscope
「KubeCon NA 2022」から、サイドカーレスを実装したサービスメッシュのIstioのセッションを紹介
クックパッドのサービスメッシュ基盤を改善した話 - クックパッド開発者ブログ
NGINXがKubernetes向けサービスメッシュ「NGINX Service Mesh」を発表
Cloud Run のサービスメッシュを試した
マイクロサービスを支える「Istio」の実力は？ サービスメッシュの利点と課題
サービスメッシュを活用して、クラウドアプリケーションのオブザーバビリティを高める | gihyo.jp
サービスメッシュのIstio、十分に成熟した段階に到達したとしてCNCFの卒業プロジェクトに
APIゲートウェイとサービスメッシュの違い | gihyo.jp
サービス メッシュについて - Azure Kubernetes Service
モノリスからマイクロサービス化してきたZOZOTOWN 16年目の新たな悩みはサービスメッシュで解決する
Traffic Director でプロキシレス サービスメッシュを試してみる
ZOZOTOWNにおける段階的なIstioサービスメッシュ化戦略 - ZOZO TECH BLOG
サービスメッシュのIstio、Cloud Native Computing Foundationへの提出を発表
Docker Swarmで学ぶサービスメッシュ - Qiita
eBPF と Wasm: サービスメッシュデータプレーンの未来を探る
2020年におけるIstioサービスメッシュの現状(翻訳記事) - inductor's blog
shonenjumpplus.com
ero-shirouto.cfbx.jp
www.dailymotion.com
www.sunday-webry.com
tabelog.com
anonymous-post.mobi