だいごろうのブログ

熊本出身で大阪、東京、パリを転勤して、今は福岡でデータエンジニアです

VisionDrivenを絵に描いてみた。

VisionDrivenの本を読んで、面白かったので、右脳で捉えるために絵に描いてみた。
books.rakuten.co.jp

詳細は、ここに書かないので、本読んでください。考え方の違いを考えるのに非常に面白い本です。
もっとみんなで妄想しましょう。

Vision思考

妄想、知覚、組替、表現の4つのサイクルについての落書き。

f:id:daigorowhite:20200229095624p:plain
vision driven

Design思考

Vision思考との差を見直すために、Design思考の落書き。

f:id:daigorowhite:20200229095629p:plain
design driven

[MEMO] katacodaでService Mesh with Istio: ver4 Simple Routings

IstioのRoutingを扱う

www.katacoda.com

oc は openshiftのコマンドです。

実践

まず、前回の章と同じ状態から、コードを変更した新しいバージョンのdocker imageをkubernetesにistioctl経由でデプロイします。

 $ docker build -t example/recommendation:v2 .
 $ oc apply -f <(istioctl kube-inject -f ../../kubernetes/Deployment-v2.yml) -n tutorial

で、podsを確認すると2つのrecommedationのバージョンが確認できます。

$ oc get pods -w
NAME                                 READY     STATUS    RESTARTS   AGE
customer-fc4cb47f9-cckgw             2/2       Running   0          15m
preference-v1-6976458fcf-96qs6       2/2       Running   0          14m
recommendation-v1-5857848d45-nb6q9   2/2       Running   0          13m
recommendation-v2-7c98cb4d-7gsgd     2/2       Running   0          11m

customer->preference->recommendationと呼び出すマイクロサービスになってるので、customerにcurlアクセスすると、v1とv2に交互にアクセスしてるのがわかる。これは、kubernetesがデフォルトだとround robinでroutingするように設定されてるかららしい。

$ while true; do curl http://customer-tutorial.2886795293-80-kitek03.environments.katacoda.com; sleep .5; done
customer => preference => recommendation v1 from '5857848d45-nb6q9': 2
customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 3
customer => preference => recommendation v1 from '5857848d45-nb6q9': 3
customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 4
customer => preference => recommendation v1 from '5857848d45-nb6q9': 4
customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 5

version2のscaleを2にすると、2対1の割合でv2,v1にアクセスするようになったのが確認できる。

$ oc scale --replicas=2 deployment/recommendation-v2

$ while true; do curl http://customer-tutorial.2886795293-80-kitek03.environments.katacoda.com; sleep .5; done
customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 15
customer => preference => recommendation v1 from '5857848d45-nb6q9': 26
customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 27
customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 16
customer => preference => recommendation v1 from '5857848d45-nb6q9': 27
customer => preference => recommendation v2 from '7c98cb4d-7gsgd': 28
customer => preference => recommendation v2 from '7c98cb4d-qsdkx': 17
customer => preference => recommendation v1 from '5857848d45-nb6q9': 28

Yamlでコントロールする

ただ、大半の用途だと、手動でアクセスの分岐をコントロールしたいはずなので、それをコントロールするためにDestinationRuleとVertualServiceの2つを設定する。

まずはBlueGreenの例かな。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: recommendation
spec:
  host: recommendation
  subsets:
  - labels:
      version: v1
    name: version-v1
  - labels:
      version: v2
    name: version-v2
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - route:
    - destination:
        host: recommendation
        subset: version-v2
      weight: 100
---
$ istioctl create -f ~/projects/istio-tutorial/istiofiles/destination-rule-recommendation-v1-v2.yml -n tutorial
$ istioctl create -f ~/projects/istio-tutorial/istiofiles/virtual-service-recommendation-v2.yml -n tutorial

これで、recommendationへのアクセスが100% version-v2に行くことが確認できる。

ここらへんのコマンドで、現在のvirtualServiceの確認ができる。

$ istioctl get virtualservice
$ istioctl get virtualservice recommendation -o yaml -n tutorial

これがカナリーリリースを行う場合。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation
spec:
  hosts:
  - recommendation
  http:
  - route:
    - destination:
        host: recommendation
        subset: version-v1
      weight: 90
    - destination:
        host: recommendation
        subset: version-v2
      weight: 10
---

こういう感じで、routingのコントロールができるみたい。

見た感じなんとなくやりたいことはわかるが、違いのわかる男になるために、ちょっと公式で勉強する。

DestinationRule

https://istio.io/docs/reference/config/networking/v1alpha3/destination-rule/

[簡易翻訳]

  • host - 簡単に言うとKubernetesに登録されてるService 名を置く。ただ、kubernetesの"reviews.default.svc.cluster.local”のような、省略しない書き方のほうが将来のミスを避けるための好まれるみたい。
  • trafficPolicy - これらを設定するところ(load balancing policy, connection pool sizes, outlier detection)。今回の設定ファイルには書かれてない。
  • subsets - ここに、各バージョンの管理を書くみたい。で、それぞれのsubesetでTraficPolicyをかける。その場合、servicelevelの設定は、上書きされる。

ラウンドロビン

  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

ハッシュ値を利用してbalancing。ユーザのCookieを利用する。

   trafficPolicy:
     loadBalancer:
       consistentHash:
         httpCookie:
           name: user
           ttl: 0s

VirtualService

traffic routingに影響する設定らしい。

[翻訳] "VirtualServiceは指定したホストへのアクセスが有った場合の、複数のtraffic routingルールの定義になる。"。

そういえば、IngressGatewayでも出てきたな。

[翻訳] 例えば、下記のKubernetes上の例だと、すべてのreviews serviceへのHTTPアクセスは“version: v1”にルートされる。そして、/wpcatalog/ or /consumercatalog/だと、 /newcatalogに上書きされた上で“version: v2”にルートされる。

で、上が先に評価される(たしか)なので、指定のURLの場合、“version: v1に転送されないはず。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
  - reviews.prod.svc.cluster.local
  http:
  - name: "reviews-v2-routes"
    match:
    - uri:
        prefix: "/wpcatalog"
    - uri:
        prefix: "/consumercatalog"
    rewrite:
      uri: "/newcatalog"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
  - name: "reviews-v1-route"
    route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1

katacodaでService Mesh with Istio: ver3 Monitoring and Tracing

Monitoring and Tracing

Prometheus と Grafana使ってるみたい。 っというか、Kubernetes周りの3rd Partyはこの2つをけっこう使ってるケースを見る。オートスケールとかPrometheusにメトリクスもたせて行ってる実装をよく目にする。

www.katacoda.com

Code

実際にyamlファイルを作成し、Prometheusにmetricsを反映させることができるみたいやな。

istioctl create -f hogehoge.yml -n istio-system

openshiftだと、このコマンドでアクセスするためのURLを取得できるみたい。

oc get routes -n istio-system

kubernetesだとどげんすっとやろ。

https://istio.io/docs/tasks/telemetry/metrics/using-istio-dashboard/

ここ見たらわかりそう。

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &

このコマンドのあとに、このURLにアクセスすると確認できた。たぶん、kubectlでポートを割り当てて、フォワードしてる。 http://localhost:3000/d/-vJFVqdWk/istio-mesh-dashboard?orgId=1

で、ちゃんと、メトリクスが追加されているか確認。 f:id:daigorowhite:20190903082032p:plain

Tips

  • kubectl port-forward どうやら、このコマンドは kubectlのローカルホストにフォワードする機能みたい。

使い方 Use Port Forwarding to Access Applications in a Cluster - Kubernetes

ちょっと詳細 Kubectl Reference Docs

あと、どうやって、このport forward止めるんだろうって、思ってたらどうやら、別に子プロセスをセッションに作ってるみたいだから、それをkillすればOK

$ jobs
[1]+  Running                 kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &
$ kill -9 %1
$ jobs
[1]+  Killed: 9               kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000

Training

OpenTracingとJaegerを利用してるみたい。これは使ったことない。 というか、ビッグデータ周りを最近やってて、このMicroServiceのトレース系をあまり触る機会がなかったな。 OpenTracingは非ベンダ依存のAPIフレームワークらしい、でJaegerはTrace用のデータを収集したり、保存、可視化したりするツール。でJaegerはOpenTracing を利用して、MicroServiceからデータの収集をしてるみたい。Zipkinを参考にJaegerが作られたみたい。何が違うのかは、別途勉強。

とりあえず、書いてあることを見ると、Istioが自動的にdataを集めて、Jaegerに送信するみたい。なので、アプリはOpenTracingとかJaegerを気にしなくて良い。

とりあえず、確認結果見れたことのキャプチャを貼っておく。 非常に便利だと思った。Zipkinと比べてみたいなぁ。なんとなく、Jaegerのほうがシンプルな感じがする。今度、勉強しよう。

Search

一つのServiceのアクセス結果リストページ。全体の結果を俯瞰的に見るときに役に立つ。 f:id:daigorowhite:20190906081226p:plain

Detail

一つのクエリの詳細ページ。極端に気になるものがあった場合のボトルネックを探せそう。 f:id:daigorowhite:20190906081302p:plain

Dependencies

APIのお互いの利用回数とか、依存関係も一目瞭然! f:id:daigorowhite:20190906081443p:plain

IstioのIngressGatewayの検証

[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl - だいごろうのブログ こっちのブログポストで気になったので、 ingress gatewayを試してみようと思います。環境作成を前のブログを参考にしてください。

Ingress Gateway

KubernetesIngress Controllerと似たような機能を Istioとかで利用できるようにするのがIngress Gatewayっぽい。

とりあえず、ここを理解してみよう。 Istio / Ingress Gateways

Istio on Minikube

Istio / Minikube どうやら、デフォルトだとメモリやCPUが全然足りないみたいなので、増やす。最初、これをしてなくて、全然、podが起動しなくて、困った。 とりあえず、メモリとCPUを倍に増やしてみる。(まだ、足りないかも)あと、minikubeのデフォルトのVMがいっぱいいっぱいになってきたので、profile変えてみる。

minikube start --memory=4096 --cpus=4 -p istio

後で気づいたが、tunnelでistioにLoadBalancerを提供できるみたい。 後日検証。

sudo minikube tunnel

Istioの確認

kubectl get svc istio-ingressgateway -n istio-system
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
istio-ingressgateway   LoadBalancer   10.110.94.62   <pending>     15020:32200/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:32445/TCP,15030:30505/TCP,15031:30605/TCP,15032:31662/TCP,15443:30531/TCP   7d

このEXTERNAL-IPがNoneやpendingの場合は、NodePortでアクセスしてくれって書いてあるな。たぶん、LoadBalancer立ててないのと、minikubeのせいで、pendingになってんのかな。 external load balancer for the ingress gatewayがないと、あかんっぽいな。

minikube + nodeportの場合は、IPとポートをこんな感じで取得

export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
export INGRESS_HOST=$(minikube ip -p istio)

公式に沿って、istio GatewayとVirtualService立てる

Gateway

kubectl apply -n istio-tutorial  -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
  namespace: istio-tutorial
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "istio.tutorial.com"
EOF

VirtualService

kubectl apply -n istio-tutorial  -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "istio.tutorial.com"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        port:
          number: 8080
        host: customer
EOF

確認

# ちゃんと設定できているかを確認
curl -I -HHost:istio.tutorial.com http://$INGRESS_HOST:$INGRESS_PORT/ -v

# アクセスを確認
kubectl logs pod/customer-59975dcff6-jwc7c -n istio-tutorial --all-containers=true -f

Ingress gatewayingress resources

Ingress gatewayingress resourcesの違いをちゃんと理解したい。今、認識ているところだと、ingress gatewayを使うと、Istioの旨味をGatewayでも利用できる点と、 既存のingress resourcesだとhttp/httpsしか、ハンドルできないんじゃないかな。

これも後でちゃんとよむ。 Ingress - Kubernetes

感想

思ったとおり、動いた!でも、Istioのインストールのときに、なぜか数分間いくつかのpodがうまく起動できなかったり、ちょっとハマった。まだ、わかってない点がおおいなぁ。kubernetesingressでも思ったが、簡単に使える点は良い。理解しなければいけないことは多いが、便利。

[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl

istioctl

どうやらこのコマンドがistioの味噌みたい。 この章ではistioctl kube-injectをメインに勉強。

Deploy.yamlにkube-injectコマンドすることで、SideCarなどの設定を自動で入れてくれるみたい。

istioctl kube-inject -f {YAML}

こんな感じでおしゃれに渡してる。

kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n namespace

Kubernetesでやってみる

Katacodaの中身がocコマンドつまりredhatのopenshiftなので、minikube立ててローカルでkubernetesでやってみた。

とりあえず、Istioをkubenetesにapplyとistioctlインストールしておく

curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.2.2 sh -
cd istio-1.2.2
export PATH=$PWD/bin:$PATH

kubectl create namespace istio-system
for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -n istio-system -f $i; done
 kubectl apply -f install/kubernetes/istio-demo.yaml
# 準備
git clone https://github.com/redhat-developer-demos/istio-tutorial/
minikube start
kubectl create namespace istio-tutorial


cd istio-tutorial
cd customer/kubernetes/

## istioctl kube-injectを確かめておこう
istioctl kube-inject -f Deployment.yml

## kubectlにappyする
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl get all -n istio-tutorial
less kubernetes/Deployment.yml

# 既存がClusterIPで外部から見れないので、NodePortも作る
cp Service.yml Servicenp.yml
vi Servicenp.yml
diff Service.yml Servicenp.yml
4c4
<   name: customer
---
>   name: customernp
6c6
<     app: customer
---
>     app: customernp
7a8
>   type: NodePort

kubectl apply -f Service.yml -n istio-tutorial
kubectl apply -f Servicenp.yml -n istio-tutorial


## アクセスしたいので, ip portを調べる
kubectl get service/customernp -n istio-tutorial  -owide

# nodeのIPがわからんかったから、 cluster-infoから引っ張ってくる
kubectl cluster-info
curl https://192.168.99.100:32318

## ほかもapply
## curlのレスポンスが変わっていくのが確認できる
cd ../../preference/kubernetes/
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl apply -f Service.yml -n istio-tutorial
curl http://192.168.99.100:32318

cd ../../recommendation/kubernetes/
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl apply -f Service.yml -n istio-tutorial
curl http://192.168.99.100:32318

最終的にはこんな感じ

kubectl get all -n istio-tutorial
NAME                                     READY   STATUS    RESTARTS   AGE
pod/customer-59975dcff6-7k8rr            2/2     Running   0          27m
pod/preference-v1-8578c48ff-mjhln        2/2     Running   0          9m7s
pod/recommendation-v1-85474b59d5-5hhg4   2/2     Running   1          7m15s

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/customer         ClusterIP   10.106.206.127   <none>        8080/TCP         19m
service/customernp       NodePort    10.111.254.169   <none>        8080:32318/TCP   20m
service/preference       ClusterIP   10.102.211.153   <none>        8080/TCP         8m57s
service/recommendation   ClusterIP   10.105.191.131   <none>        8080/TCP         7m11s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/customer            1/1     1            1           27m
deployment.apps/preference-v1       1/1     1            1           9m7s
deployment.apps/recommendation-v1   1/1     1            1           7m15s

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/customer-59975dcff6            1         1         1       27m
replicaset.apps/preference-v1-8578c48ff        1         1         1       9m7s
replicaset.apps/recommendation-v1-85474b59d5   1         1         1       7m15s

どんな感じで、コードの方は定義されてんやろう。どうやって、istioを利用してるんだろう。

customer -> preferenceで名前解決してるところはどうやら単純に、preferenceをhostとして指定するだけみたい。

preferences.api.url=http://preference:8080

https://github.com/redhat-developer-demos/istio-tutorial/blob/master/customer/java/springboot/src/main/resources/application.properties

同じnamespaceのserviceにservice名でアクセスできる感じかな。あとでもっと理解する必要ありそう。ただ、docker-composeと同じように名前をつけれるので、ローカルではdocker-composeで開発して、kubernetesデプロイ時にはistioに名前解決させるで良さそう。

ingress gateway

よく考えたら、serviceのnodeport使わなくても、 ingress gatewayからアクセスとかできるんじゃないかな。ちょっと検証してみよう。ただ、長くなってきたから、別のブログポストにまとめます。

TBD

まとめ

istioのサポートがアツい。kubernetesへの導入の簡単さ、違和感なくkubernetesを使えてる感じ。すごい。

あとで読む。 https://istio.io/docs/concepts/traffic-management/

[更新中] Docker初心者向けコンテンツまとめ

ゴール

社内でDockerを勉強した人がいたので、ちょっと、情報をまとめてみた。 今(2019/08/01)、僕の認識してるところだと、大きな障壁が英語である。DockerとかはVMとの違いは何かなどの考え方の違いの理解が多く必要だと思うので、英語に慣れていない人だとハンズオン系のものが足りなく感じるので、このページで、どこらへんを見て勉強すれば良いかの目印を作れればと思う。 このページは、Docker自体については、記述しないし、今現在の情報を載せるつもりです。こういうのもあるよってあれば、教えてほしいです。

ハンズオン系

英語

katacoda

今の所、一番好き。オンラインでできるので、dockerのインストールもいらないし、どんな環境からもやりやすい。Katacoda内にkubernetesもあるし、幅広いコンテンツもあるので、 www.katacoda.com

learndocker

VideoとQuizzeに分かれていて、理解度を確認しながら進めるみたい。 githubのアカウント連携を求められる。

f:id:daigorowhite:20190801084228p:plain
learndocekr
learndocker.online

sample code

Dockerの公式。サンプルコードがたくさんあるし、Tutorial labsのチャプターで自分のユースケースに合わせて、勉強すれば感覚がつかめるんじゃなかろうか。 docs.docker.com

日本語

入門 Docker

パット見た限りであるが、初心者向けには良さそうでさる。絵を使って概念の説明と、利用コマンド例が入ってる。資料にそって、練習するだけで基本は身につきそう。 y-ohgi.com

Video

英語

youtube

12分で、Dockerの基本を紹介してる。初めてだときついかも。 Learn Docker in 12 Minutes 🐳 - YouTube

udemy

Udemy。Docker,Kubernetesまでをカバーしており、今の所一番人気っぽい?1万円くらい。 https://www.udemy.com/docker-and-kubernetes-the-complete-guide/

日本語

udemy

Udemy。1万円くらいするが、日本語で教えてくれると思うと安い。 https://www.udemy.com/docker-k/

他の紹介サイト

さすが、英語だと大量にコンテンツある hackr.io

引き続き更新していきます。2019/08/01

[MEMO] katacodaでService Mesh with Istio: ver1 Istio Introduction

前回までKubenetesをやってたんですが、続いて、ServiceMeshも正しく理解したくて今回から別のコースをやって行きたいと思います。

勝手に名言「正しい判断は正しい知識から。」( ー`дー´)キリッ

www.katacoda.com

公式も後で読もう。 istio.io

Istion/ServiceMesh Introduction

ServiceMeshはMicroServiceのネットワークあたりの用語としてよく使われる。 MicroServiceが増えてくるとdiscovery, load balancing, failure recovery, metrics, and monitoringあたりが必要かつ難しくなってくる。また、ここらへんも求められちゃう A/B testing, canary releases, rate limiting, access control, and end-to-end authentication。

Istio

Istioはservice meshの振る舞いのInsightや運用管理を可能とする。

  • traffic管理 : Service感の通信の管理
  • 管理能力 : どのpodがどのservice使ってんの
  • Policyの施行 : serviceを超えてpolicyをひとまとめに管理できる的な? Meshの設定でそれを管理するので、全体でフェアなリソース管理になるって感じかな
  • Serviceのidentityとセキュリティ : サービスの認証あるから、セキュリティも担保しやすい。てきな

Istioは最初Kubernetesのために作られたが今はMesosなどにも対応してるし、onPre,Cloudどちらもおーけー。あと、Policyなどはカスタマイズ可能で、ACLs, logging, monitoring, quotas, auditing ここらへんを自由に付け替え可能らしい。

DataPlane / ControlePlane

https://istio.io/docs/concepts/what-is-istio/#architecture

data plane

intelligent proxies (Envoy) のセットで、SideCarとしてデプロイされる。MicroService間のネットワークをコントロール。proxyの仲介を行う。Mixerから設定を読み取るっぽい。 (TODO SideCar勉強しないと。)

control plane

control planeはproxyの管理を行う。Mixerの調整を行う。

Envoy

Envoyはhigh-performance proxyです。PodのSideCar としてデプロイされるDataPlane。 Pilotから設定を受け取りServiceのインバウンド・アウトバウンド両方のTrafficの仲介・管理・監視を行うっぽい。

Mixer

MixerはPlatform非依存のコンポーネント。ServiceMeshの中で、アクセスコントロールとポリシーの利用を強制する役割を持つ。Proxy(Envoy)からそれらの設定へのアクセスを一任する MixerはControl planeの一つのAPIでProxyの設定の保持とData Planeへの公開を担当してるみたい。

Pilot

Pilot はEnvoySidecar向けのサービスディスカバリ, intelligent routingのためのTraffic管理能力を提供してる。まぁ、つまり、それらの設定をproxy(Envoy)に配布する役割 Pilotを使うことで、Trafficの管理ができる。5%はこのサービスに送るとかCanaryリリースが可能。特定のTrafficはこっちのバージョンに送るとか。

Citadel

Citadelはサービス間やユーザの認証とCredential管理を行う。Citadelを利用することで、ネットワークの制御でなく、Serviceの認証による管理が可能になる。的な。