マイクロサービスシステムの実現 - inthecloud.withgoogle.com€¦ · 自己紹介...

Google Cloud

Anthos Day

Istioを利用したモダンな

マイクロサービスシステムの実現

株式会社ユーザベース

生賀一輝 / 鈴木祥太

1. 紹介

2. 従来システム構成とその課題

3. マイクロサービスの採用

4. マイクロサービスの運用とエコシステムの活用

5. 今後について

アジェンダ

01紹介

生賀一輝株式会社ユーザベース

仕事：SPEEDA の SRE を担当

好き：landscape / CRD

好きな GCP の Service：

趣味：コンテンツ巡り

自己紹介

Twitter：@skikkh Facebook//ikki.shoka

鈴木祥太株式会社ユーザベース

仕事：SPEEDA の SRE を担当

好き：Kubernetes / Network

好きな GCP の Service：

趣味：映画

自己紹介

Twitter：@sshota0809

z

社名：株式会社ユーザベース / Uzabase, Inc.

創業：2008年4月1日

本社所在地：東京都港区六本木 7-7-7 TRI-SEVEN ROPPONGI 13F

事業内容：企業活動の意思決定を支える情報インフラの提供

上場市場：東証マザーズ（ 3966）

COMPANY OVERVIEW

提供サービス：

経済情報プラットフォーム

ソーシャル経済メディア

スタートアップ情報プラットフォーム

B2Bマーケティングプラットフォーム

米クオリティ経済メディア

サブスクリプションビジネスに特化したテーマ型ファンド

-7-

-7-多様なニーズを持った

多様な顧客

多くの

データサプライヤー

700 万社を超える

超巨大な企業 DB

02従来システム構成とその課題

全体構成

Load Balancer

CDN

Web

App

Database

Batch Session ElasticSearch

従来から多く存在する 3 層構造

サービスとしての機能は App 層に集中

BtoB 向けの経済情報プラットフォーム

事業開始当初から多様な顧客のニーズに

対応するために膨大な数の機能実装を行う

❏ 一人ひとりの顧客を大切にする

2 つの大きな課題

アプリケーションの拡張性 Blue / Green デプロイの複雑性

機能

機能

機能

機能

機能

機能

Blue Green

Web

Blue / Green デプロイの複雑性

Blue Green

Web

アプリケーションの拡張性

機能

機能

機能

機能

機能

機能



機能が増える度に肥大化し続ける

密結合になってしまう

❏ どこかを改修したら別の部分に

影響がでてしまうリスク

❏ 各機能のリリースを独立した形で

並列に行うことができない

App を乗せるインフラも塩漬けになりやすい

❏ アプリケーションの大きさの影響を受け、

インフラの Update や移行がスムーズに進まない

Application

機能 A 機能 B

機能 C 機能 D

・・・

新規機能

肥大化し続ける新規機能新規機能

1つの大きなアプリケーション


機能

機能

機能

機能

機能

機能


Blue Green

Web



Blue Green

管理用 API

Blue : upGreen : down

開発者

Web

App App

Apache で Blue / Green の振り分けを実施する

❏ Apache の mod_proxy_balancer を利用

❏ 管理用 API 経由でトラフィック制御する

❏ トラフィック制御に関する情報は

永続化されないためApacheをrestartすると

消えてしまう

WEB 層で Blue / Green の制御


Blue Green

Web

App App

or

ジョブ

デプロイは Jenkins で制御

エンドポイントが増える度にジョブの中身が肥大化

トラフィックフローの可視化ができない

Blue / Green どちらが現在 active か調べる場合

管理用 API 経由でステータスを確認する必要あり

❏ 全エンドポイントのステータスを表示する

お手製シェルを実装するが運用しづらい状態


機能

機能

機能

機能

機能

機能


Blue Green

Web


モノリスアプリケーションの拡張性


独立しているはずのそれぞれの機能が密結合になってしまう

❏ 事業の進化のスピードに追いついていない

Apache Module の仕様により運用コストが肥大化

無数のエンドポイントのトラフィックフローが全く可視化されていない

❏ 障害時の調査時などに大きなボトルネックを生み出してしまう

03マイクロサービスの採用


アプリケーションの拡張性 Blue / Green デプロイの複雑性

機能

機能

機能

機能

機能

機能

Blue Green

Web



Blue Green

Web


機能

機能

機能

機能

機能

機能

マイクロサービスを

採用することで解決

Microservices アーキテクチャの採用

機能 A 機能 B

機能 C 機能 D

機能 E 機能 F

機能（Service）毎に独立

それぞれの機能が疎結合になる

❏ 機能毎にリリースやオペレーションが可能

➡ 事業のスピードを加速させることができる

❏ 障害範囲を局所化することができる

コンテナオーケストレーションツール

Kubernetes を採用

❏ コミュニティが活発

➡ プロダクトの素早い進化を望める

➡ エンジニアとしての技術力を高める



機能

機能

機能

機能

機能

機能


Blue Green

Web

Istio を

採用することで解決

Kubernetes によるトラフィック制御の問題点

Blue Green

機能 B 機能 B

機能 BService

機能 AKubernetes では要件は満たせない

柔軟なトラフィック制御ができない

❏ Service リソースの selecotor を変更？

❏ カナリアリリースをしたくなったら？

❏ トラフィックフローの可視化は？

Kubernetes によるトラフィック制御の問題点

Istio

Blue Green

機能 B 機能 B

機能 BService

機能 A

Istio で Blue / Green デプロイの実現

Istio により柔軟なトラフィック制御が可能

複雑に絡み合うマイクロサービスの整理

Kiali 等を利用することで可視化

➡ 障害時等にも素早い原因調査が可能

04マイクロサービスの運用と

エコシステムの活用

Kubernetes による統一された環境の提供

オンプレ GCP

開発者

Pods AKubernetes

Pods BKubernetes

Kubernetes という一貫した基盤

❏ 開発者はオンプレ / GCP といった違いを意

識する必要がない

❏ 容易にオンプレ / GCP を横断した

アプリケーションのデプロイが可能

➡ ポータビリティ性

Istio の導入

Istio には様々な機能が実装されている

❖ Traffic Management

❖ Security

❖ Policies

❖ Observability

Istio の導入

Istio には様々な機能が実装されている

❖ Traffic Management

❖ Security

❖ Policies

❖ Observability

本セッションでは

Traffic Management について主にお話します

Istio のアーキテクチャ

Service A

Service B

Istio IngressGateway

*.fuga.com

*.hoge.lan

b.svc.cluster.local

機能 B

Pod B

機能 A

Pod A

Istio によって各 POD にサイドカー Proxy がデプロイ

各 POD への In / Out トラフィックは全て Envoy (Istio Proxy) を経由

➡ Istio によってトラフィック制御が可能になる


Service A

Service B


*.fuga.com

*.hoge.lan

機能 B

Pod B

機能 A

Pod A

クラスタ外からの通信について

外部 Gateway として Istio Ingress Gateway がデプロイされる

➡ 外部からの通信を経由させることで Istio によりトラフィック制御される

Service: 機能 A

Blue

Green


機能 AKubernetes

機能 AKubernetes

VirtualServiceResource

DestinationRuleResource

論理的な経路

実際の経路

PODInside Cluster


Istio のトラフィック処理について


Service: 機能 A

Blue

Green

機能 AKubernetes

機能 AKubernetes


論理的な経路

実際の経路VirtualServiceResource


PODInside Cluster

❏ Host header が hoge.com に対してルールが適用

❏ path が /* であれば、

❏ 指定した host(service) の subset: blue に通信



Service: 機能 A

Blue

Green

機能 AKubernetes

論理的な経路

実際の経路

機能 AKubernetes


PODInside Cluster



❏ subnet: blue であれば、

❏ version: blue ラベルがついた POD に通信


Service: 機能 A

Blue

Green


機能 AKubernetes

機能 AKubernetes



論理的な経路

実際の経路

PODInside Cluster



Pod A

:15000

Envoy に関する各種情報へのアクセス

:15000 に HTTP アクセスすることで様々なステータスを確認可能

➡ デバック等に役立つ

Microservices 運用において考慮すべきこと

Kubernetes とIstio の導入だけで

すべてが解決するのか？


CI/CD 可視化 API の統合管理

監視/ロギング Service Discovery

…...…….....……..………...…….

可視化 API の統合管理


…...…….....……..………...…….

CI/CD


Blue / Green Deployment フロー

buildkite-agent

管理 UI Deploy 実行

pipeline 抜粋

CI/CD ツールとして Jenkins や BuildKite を使用

BuildKite の利用について

❏ YAML でパイプラインが記述可能

❏ Managed な環境でパイプライン管理が可能


Blue / Green 切り替え

Docker Imageの作成

コンテナのデ

プロイ

パイプラインを分割


コンテナのデ

プロイ


Blue / Green切り替え Pipeline について説明



コンテナのデ

プロイ


細かいフローに沿って説明



クラスタに

デプロイ

デプロイ先カ

ラー

選択

Manifest生成

クラスタに

デプロイ

Manifest生成

デプロイ先カ

ラー

選択

WEB GUI から選択


クラスタに

デプロイ

デプロイ先カ

ラー

選択

Manifest生成

シェルスクリプトを使用



virtual-service.yaml

Blue

Green

アクティブ

buildkite-agent

blueorgreen

デプロイ用シェルが実行され、

マニフェストファイルを生成

デプロイ先カ

ラー

選択

Manifest生成

クラスタに

デプロイ

ジョブサーバから

kubectl でデプロイ



virtual-service.yaml

Blue

Green

アクティブ

buildkite-agent

デプロイ

生成したマニフェストファイル

をクラスタにデプロイ

CI/CD API の統合管理


…...…….....……..………...…….

可視化


Kubernetes における可視化の課題

？ : Pod

増え続けるマイクロサービス

各チームが日々デプロイし続け巨大になるマイクロサービス網

➡ マイクロサービス網の全体を把握しきれない

➡ 障害発生時の調査等が難航するリスク

Kubernetes における可視化の課題

POD

Blue

POD

Green

Service: B

POD

Blue

POD

Green

Service: A

POD

Blue

POD

Green

Service: D

POD

Blue

POD

Green

Service: C

POD

Blue

POD

Green

Service: E

xx msxx ms

xx ms

xx ms

導線の中に隠れているボトルネック

マイクロサービス同士が様々な通信をし合っているため、

一気通貫したトラフィックフローの中でボトルネックを探しにくい

Kiali を利用した ServiceMesh の可視化

20 ms

: Pod

5 ms

15 ms8 ms

11 ms

Kiali の導入により ServiceMesh の情報を可視化可能

様々な情報を視覚的に確認することができ、

障害ポイントの特定やボトルネックの特定を迅速に行うことができる

・トラフィックフロー

・レイテンシー

・エラー割合等


Service A

お手製スクリプト等も必要なく視覚的に

迅速に現在のステータスを確認可能

Blue / Green デプロイのステータスも確認可能

CI/CD 可視化


…...…….....……..………...…….

API の統合管理


エンドポイント管理における課題

・・・

管理 / 実装コストがかかってしまう開発者が望んでいない部分でのコストが肥大化

機能 C

domain-C

機能 A

domain-A

機能 D

domain-D

機能 B

domain-B

増え続けるエンドポイント

❏ 大量のドメイン管理が必要

❏ アクセスログ等もコンポーネント毎になる

❏ 認証機能の実装

➡ コンポーネント毎に実装する必要がある

Kong による API の統合

・・・

domain-kong

/path_A

/path_C /path_D

/path_B

認証

Plugin

モノリス App

機能 C

機能 A

機能 D

機能 B

Kong を利用することで API を統合管理

❏ Kong が通信を中継するためログの集約

❏ API に対しての認証機能を Kong で統合

➡ 各コンポーネント側で認証機能を

意識 / 実装する必要がなくなる

➡ 認証機能はモノリス App 側にあるため


YAML の形で config が記述可能

❏ plugin を利用することで柔軟な設定が可能

❏ 弊社では tarzan という

独自の認証 Plugin を実装して利用

❏ Logging や流量制御等も設定可能

POD

Envoy

UID: 1337

UID: 1337 Envoy のプロセスは istio-proxy ユーザで動作

istio-proxy の UID は 1337

❏ UID 1337 からのパケットは無視する

❏ Kong の UID も 1337 のため Kong の通信が

うまくトラフィックコントロールされない

事象が発生 (Issue #257)

実運用でハマったケースの紹介


https://github.com/Kong/docker-kong/issues/257

POD

Envoy

UID: 1337

UID: 1337 Envoy のプロセスは istio-proxy ユーザで動作

istio-proxy の UID は 1337

❏ UID 1337 からのパケットは無視する

❏ Kong の UID も 1337 のため Kong の通信が

うまくトラフィックコントロールされない

事象が発生 (Issue #257)

実運用でハマったケースの紹介

複合的な状況で発生する

トラブルもよくある


https://github.com/Kong/docker-kong/issues/257


Service Discovery監視/ロギング

…...…….....……..………...…….


Kubernetes の監視 / ログ収集の統合

Kubernetes

POD POD POD

pull

▼ https://istio.io/docs/reference/config/installation-options/#prometheus-options

Istio

Mixier Helm で Istio をインストール

❏ デフォルトで Prometheus がインストール

❏ Istio 周りの Metrics を収集してくれる


Istio

Istio

Istio

Istio

Istio

Istio

Istio

各 Kubernetes クラスタの情報を集約する必要がある

クラスタ毎に Alert 設定等する運用は辛い


federate

Istio Istio Istio Istio

各 Prometheus の federate 機能を使い全クラスタの情報を集約

GCP


Stackdriver

オンプレミス

k8s #1 k8s #2 k8s #3

GKE のログは Stackdriver に集約される

オンプレミスのクラスタに関しては

何か設定をしない限りはログ転送等はされない

GKE #1 GKE #2 GKE #3

GCP


Stackdriver

オンプレミス

k8s #1 k8s #2 k8s #3

共通したインターフェースでログを見たい


GCP


Stackdriver

オンプレミス

k8s #1 k8s #2 k8s #3

GCP 公式の fluentd Plugin を改修し、

オンプレミスのクラスタ対応を実施


GCEfluentd-forwarder

GCP


Stackdriver

オンプレミス

k8s #1 k8s #2 k8s #3

オプションを付与することでオンプレ用の

タグを付与して Stackdriver に保存


GCEfluentd-forwarder


Stackdriver の画面からオンプレの cluster のログが閲覧可能に

GKE-1

GKE-2

オンプレ-1

オンプレ-2


監視/ロギング

…...…….....……..………...…….

Service Discovery


Kubernetes における DNS 運用の課題

Service

Service リソースをデプロイする度に増えるエンドポイントに対して

静的に DNS の名前解決設定をするのでは運用負荷が高い

External IP(type: LoadBalancer)

ext.hoge.uzabase.com ext.fuga.uzabase.com・・・

PODPODPOD

LoadBalancer

IP A

PODPODPOD

LoadBalancer

IP B

PODPODPOD

LoadBalancer

IP C

PODPODPOD

LoadBalancer

IP D

PODPODPOD

LoadBalancer

IP E

Dynamic な DNS の実現

クラスタ外向けの CoreDNS を用意することで解決

➡ 各クラスタにドメインを与えてそれぞれの CoreDNS にフォワード

Cloud DNSext.cluster-a.uzabase.com ext.hoge.uzabase.com

ServiceService

Service

PODPOD

Service

LoadBalancer

ServiceService

Service

PODPOD

Service

LoadBalancer

ServiceService

Service

PODPOD

Service

LoadBalancer

CoreDNS


CoreDNS の k8s_external プラグインを利用

➡ External-IP (type: Load Balancer) を Dynamic に解決することができる

https://github.com/coredns/coredns/tree/master/plugin/k8s_external

https://github.com/coredns/coredns/tree/master/plugin/k8s_external


NameSpace

Service




…...…….....……..………...…….

05今後について

今後のライフサイクル（Anthos 導入）

GKE gen.1 / オンプレ gen.1


Anthos01 / etc...


20XX 3Q 20XX 4Q 20XX 1Q 20XX 2Q 20XX 3Q

現行クラスタ

新しいバージョンのクラスタは

running 期間として旧クラスタと並行稼動


クラスター / ポリシー管理

Anthos の有用性検証

❏ Anthos でオンプレミスやパブリッククラウド上の

クラスタやポリシーを統合管理することが可能

❏ その有用性等について検証していく予定


istio ver1.0

istio ver1.2

istio ver1.7?

istio ver1.4

現行クラスタ

20XX 3Q 20XX 4Q 20XX 1Q 20XX 2Q 20XX 3Q

クラスタのライフサイクルに合わせて

Istio も最新バージョンを追従

Thank you

マイクロサービスシステムの実現 - inthecloud.withgoogle.com€¦ · 自己紹介...

Documents