【概要】
2019/3/13 (水)に↓のセミナーがあったので行ってきました。
Build with Containers! - AWS で構築する実践的コンテナワークロード
https://pages.awscloud.com/BuildwithContainerseminar20190313-jp.html
そこでの内容をメモった内容をそのままアップしますー。
【注意】
- メモをそのまま載せてるだけなので、誤字脱字があります
- 書ききれてないところとかは私の英語力や理解力が低かった結果です
- 後日スライドが共有されるそうなので、追記します
- 後日内容の深掘りをしていこうかとは思ってます
- 正直、理解できてないことも多いです
===========
【イベントメモ】
k8sについて
なぜコンテナ?
- どの環境でもちゃんと使えなきゃだめだよね
- フェーズなのか、どこでそれを実行するのかということも気にしなきゃいけない
- また、各環境でのマシンのversionは?それのせいで上手くいかないこともあった
- コンテナはマシンに関係なく、コードやエンジンなどを全て一つのパッケージにしてくれるから気にしなくて良くなる!
- containerはDockerが出てから初めて一般大衆も使えるようになったね
- Dockerは→2つが重要「作ったイメージは不変なものである」「レイヤー化されているので関係されている部分だけ直せばいい」
container をオートスケールさせるときは?
- デバッグもモニタリングも難しいよね
- 全てのコンテナをstart / stopする必要あるし、
- コンテナのロールアウトとかいろいろやる必要ある
- だから自動化したいよね
- ↑はk8sとECSを使おう
CNCF
- Cloud Native Computing Foundation
- クラウドに関連したオープンソースプロジェクトが身を寄せる事務管理団体
k8s細かく見ていこう
構成
- kubectl
- これは、だいたいみんな知ってるよね
- これで開発ほぼほぼ網羅できるよ
- kubectlを介してAPIサーバーの方に全て投げられる
- k8s masterにkube-api, schedulerを含んでいる
- kubectl→ API→ APIコール→ 様々な操作 という流れ
- Pod
- 実装の際の最小単位
- 1~nのコンテナが含まれる
- Deamon Set
- PodのコピーがきちんとNodeに行くようにしてくれる子
- 一番典型的な使い方はエージェントとか
- Deployment
- なにかこのk8sで開発したい場合はこの概念で行う
- Podが複数アプリに展開される必要があるので、Deploymentではこれの状態が管理される
- 2つの状態がある
- Replica setの管理: Podのマネージをする。e.g. Podが5つ必要な場合、必ずこれで管理する
- ツール: rolling update, upgrade
- Job
- ちゃんとPodが仕事したかどうかを管理するやつ
- Service
- いわば、抽象化をしてくれる領域
- Podを抽象化して実装するサービス
- コンセプトとして、lavelセレクタという概念がある
- key-valueのペアになってる
- Namespaces
- k8s=cluster, namespace=パーティション
- namespaceは独立している
- Node = インスタンス
- Network Architechture
- clusterは「Contorl Plane」「Data Plane」でなっている
- Contorl Plane
- API Server: ポッド、サービス、複製コントローラーなどを含むAPIオブジェクトのデータを検証して構成します。 APIサーバーはREST操作を処理し、他のすべてのコンポーネントがやり取りするためのクラスターの共有状態へのフロントエンドを提供します。
- Etcd: key/valueのストア Replicasetであれ、全てここに格納されている
- Controller-manager:
- Schecduler: クラスタの中の正しいNodeにPodを置く
- Data Plane
- WorkerNode: AWSならEC2が乗っている
- Kubelet: 正しい数のPodがあるように管理している
- kube-proxy: Podの方にトラフィックをルーティングする
-
Scheduling
- まずは、クラスタ上のリソースをどこにいくらかを操作する必要がある
- これはnamespaceで割り当てる
- 2つのパラメータをコンテナに設定できる
- 1. リソースのリクエスト:このコンテナに対して、最低このくらい使えますよーを保証する
- 2. リソースのリミット:Maxのしきい値
- Resource Quotas:
- Namespaceがマックスで使えるQuotas
- Podのスペック:
- containerの中でどのくらいのスペックが使えるかを定義
- total quotasが決まってるので、その値を超えないように設定する必要がある
- Production / developが共有してあるのなら、production側の設定を超えないように気をつける必要がある
- どのポッドがどのNodeに割り当てられる?
- taints:
- Nodenに対する設定
- key, value設定できる
- tolerations:
- Podに設定するもの
- key, valueに対する effect
- ↑と設定が合致する必要がある
- あくまでもこの設定は可能性(絶対あるものではない)
- Affinity / Anti-Affinity
- Required
- Optional
- Required
- taints:
- auto scale
- いくつか方法がある
- cluster scale
-
clusternのnamespaceに関する質問
- 各環境用に分けたほうがいい?
- 基本的には大きな単位での設定をお勧めしている
- clusterは大きければ大きいほどいい
- もちろんそうではないシナリオもあります。Productionだけにして他の環境に影響出したくない!という場合であれば、違うcluseterにしたほうがいいです
- 細かなclusterを管理する煩雑さはさじ加減はうまい具合で頑張って
- 経験では、一つのclusterの中に数百のnamespaceを持っている人もいましたが、会社の状況鑑みて
- cluster分けると、オブジェクトの数でコントロールPlaneに影響が出るから注意
- 各環境用に分けたほうがいい?
-
EKS
- 51% 動いてるよ
- 楽にk8s使えるようにしました
- EKSでできること
- AWSがControl planeを管理する
- ユーザーは独自のEC2インスタンスを持ち込んで、完全にコントロールすることができる
- EKSの中核的な理念として、productionで使いやすようにしてる
- EKSの中で体験したものはk8sの発展に生きていく(Feedbackされる)
- k8sでやってることはEKS上で行っていることで絶対できるよ (逆もしかり)
- 物理的に離れているデータセンター(AZ)もclusterのように捉えられる
- =DRに強い
- 複数のAZをまたいでclusterを立てることでDRに強いサービスになる
- EKSの立ち上げには
- cluster create
- create HA controll plane
- worker node
- IAMを使ってcluster上でアクセスできるようにする
- cretificate management
- setup LB
- cluster create
- EKSのConroll planeはEKS VPC上に立ち上げられる(AWSが立ち上げている)
- controll plane用のアップグレードには2つの方法がある (最近APIを公開したばっか)
- マイナーバージョンでclusterを作ってる時、platform展開をAWSから促すことになる
- この数週間でCDEなどがあったので、AWSがユーザーに対してパッチを当てるなどをしました
- もう一つは 1.12とかのバージョンアップであればマニュアルAPIを利用してやってね
- Master Nodeは複数持っている
- MasterからWorker Nodeに通信する場合は、「Cross ENI」をつくるひつようがある
- Master - WokerNode通信にはTLSが必要 =
- master側でPKIの発行が必要
- Woker Node側で kubelet install server cert が必要
- セキュリティ担保のため、 WokerNodeで発行した証明書は一定時間で更新する必要がある
- EKSじゃないと、これはめんどくさいよ
- CNI (container networking interface)
- CNIの仕組みはVPCとk8sのネットワークを統合する役割
- EC2のノードは一定数のENIを割り振ることが可能
- 各ENI毎にセカンダリIPが振られている
- ENIの数、セカンダリIPの数は全てインスタンスによって違います
- e.g. c4.largeだと4つ、みたいな
- 簡単に言うと、VPCにIPが付与できるようになる機能
- 結果、overlayのnetworkも発生しないし、パフォーマンスを上げていくことが可能
- cluster Identity & Access Management (IAM)
- clusterのロール管理にIAMが使える
- k8s用のIAMがある => IAM roles for Kubectl "aws-iam-authenticator"
- local (kubectl) → k8s api する時に、AWSの認証が必要
- 権限をIAMの情報を参照して、k8sのRBACに紐づけて、与えられた権限分アクセスできるようにする
- RBAC
- Podに対して、どんなことができるかをrole毎で管理する仕組み
- user, group, service account毎でbindできる
- user = IAM userと紐づく
- Metrics (モニタリング)
- どういうオプションあるか
- logの収集
- Node:node exporter
- Pod/Container:cAdvisor
- Application:JMX
- Clusterを横断してlog取りたい時:
- Prometheus
- Heapester
- Data Model:
- InfluxDB
- Graphite
- Alert:
- AlertManager
- Kapacitor
- Visualizer:
- Grafana
- Kibana
- Dashborad
- logのAggregationとしてよく使われるのはCloudWatch LogにFluentdを使う方法が利用される
- monitaring, tracing, loggingこれができてればサービス運用は問題なし
- Tracing
- App Methの時に詳しく話します
- tracingによって、問題分析とかマイクロサービスの可視化とかもできるようになりますよ
======================
haraさんによるマイクロサービスのデモ
Live
- Pod, Jobとかさっき出てきたけど、いろいろあるよね
- でもいろいろある意味ってなんだろう?
- Podが中心
- リソースが細かく定義されているので、アプリ開発者としては少ないyamlで定義できる
ECSは、タスクとサービスしかないから直感的に分かりづらいよね
ユーザーがやってほしい方向(状態を宣言)に寄せる = コンテナワークロードの基本
↑命令じゃなくて宣言なので注意
UP-TO-DATEは自分がやってほしい状態にあるPodがいくつあるか
editという闇コマンドがあるので、これは基本使わないでね! (docker exec 然り)
-
k8sもEC2立てた時のやつと一緒(VPC立てたり、ルーティングしたり、、、) さいしょは プライベートサブネットにEC2立てるようなもの
$ kubectl expose deployment hello-world --type=LoadBalancer --name=my-service service/my-service exposed
→ これは嘘。これから設定をするので、まだexposeできてないよ
$ kubectl get services my-service -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR my-service LoadBalancer 10.110.79.237 localhost 89:31232/TCP 39s run=load-balancer-example
→ EXTERNAL-IPがパブリックDNSのようなもの
→ type=LoadBalancerは使わないことを推奨(これはELB/ALBを別に流すほうがいいよ)ライフサイクルが違うのでcontainers: - image: apache
に書き換える。
etcdにあるkey:valueが書き換わって、その状態を検知して、ローリングアップデートが走って、中身を変える$ kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE hello-world 5 7 3 4 14m
→ 新しいのに書き換わってる
$ kubectl get pods NAME READY STATUS RESTARTS AGE hello-world-56d69dc874-5wtbp 0/1 ErrImagePull 0 1m hello-world-56d69dc874-8nlzd 0/1 ErrImagePull 0 1m hello-world-56d69dc874-tdk4d 0/1 ErrImagePull 0 1m
- image: httpd
に変更
$ kubectl get pods -w NAME READY STATUS RESTARTS AGE hello-world-7489dddb56-5pq92 1/1 Running 0 15m hello-world-7489dddb56-cgqtq 1/1 Running 0 15m hello-world-7489dddb56-h9fvr 1/1 Running 0 15m hello-world-7489dddb56-qdgl7 1/1 Running 0 15m hello-world-75d7ff75cb-7kzqf 0/1 ContainerCreating 0 4s hello-world-75d7ff75cb-7nqpx 0/1 ContainerCreating 0 4s hello-world-75d7ff75cb-l6hgw 0/1 ContainerCreating 0 4s pingpong-1549408800-hdl7q 0/1 Completed 0 35d pingpong-1549409100-92lrt 0/1 Completed 0 35d pingpong-1549409400-sk2n9 0/1 Completed 0 35d hello-world-75d7ff75cb-l6hgw 1/1 Running 0 11s hello-world-7489dddb56-qdgl7 1/1 Terminating 0 15m hello-world-75d7ff75cb-rl8fk 0/1 Pending 0 0s hello-world-75d7ff75cb-rl8fk 0/1 Pending 0 0s hello-world-75d7ff75cb-rl8fk 0/1 ContainerCreating 0 0s hello-world-7489dddb56-qdgl7 0/1 Terminating 0 15m hello-world-75d7ff75cb-7kzqf 1/1 Running 0 13s hello-world-7489dddb56-h9fvr 1/1 Terminating 0 15m hello-world-7489dddb56-qdgl7 0/1 Terminating 0 15m hello-world-75d7ff75cb-nzthm 0/1 Pending 0 0s hello-world-75d7ff75cb-nzthm 0/1 Pending 0 0s hello-world-7489dddb56-qdgl7 0/1 Terminating 0 15m hello-world-75d7ff75cb-nzthm 0/1 ContainerCreating 0 0s hello-world-7489dddb56-h9fvr 0/1 Terminating 0 15m hello-world-7489dddb56-h9fvr 0/1 Terminating 0 15m hello-world-7489dddb56-h9fvr 0/1 Terminating 0 15m hello-world-75d7ff75cb-7nqpx 1/1 Running 0 17s hello-world-7489dddb56-cgqtq 1/1 Terminating 0 15m hello-world-7489dddb56-cgqtq 0/1 Terminating 0 15m hello-world-7489dddb56-cgqtq 0/1 Terminating 0 15m hello-world-7489dddb56-cgqtq 0/1 Terminating 0 15m hello-world-75d7ff75cb-rl8fk 1/1 Running 0 9s hello-world-7489dddb56-5pq92 1/1 Terminating 0 15m hello-world-7489dddb56-5pq92 0/1 Terminating 0 15m hello-world-7489dddb56-5pq92 0/1 Terminating 0 15m hello-world-7489dddb56-5pq92 0/1 Terminating 0 15m hello-world-75d7ff75cb-nzthm 1/1 Running 0 10s
-w で監視できる。作成できた
お片付け
$ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer 10.110.79.237 localhost 89:31232/TCP 7m $ kubectl delete svc my-service service "my-service" deleted $ kubectl get deploy NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE hello-world 5 5 5 5 18m $ kubectl delete deployment hello-world deployment.extensions "hello-world" deleted
→ k8sのetcdに登録されているものが消えるだけ
コマンド一覧
```
505 echo "demo"
506 kubeclt get nodes
508 kubectl get ns
509 kubectl get pods --all-namespaces
510 echo "↑ issue basic commands"
512 kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=nginx --port=80
513 echo "↑これは原理主義者にいうと怒られる"
514 kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=nginx --port=80
515 k get deployment
516 kubectl get deployment
517 kubectl get pod
518 kubectl edit deployment hello-world
519 kubectl expose deployment hello-world --type=LoadBalancer --name=my-service
520 kubectl get services my-service -o wide
521 kubectl edit deployment hello-world
522 kubectl get deploy
525 kubectl get pods
526 kubectl edit deployment hello-world
527 kubectl get pods -w
528 kubectl get pods
529 kubectl get svc
530 kubectl delete svc my-service
531 kubectl get deploy
532 kubectl delete deployment hello-world
```
======================
ECS のセッション
AWS Fargate
なぜFargate作ったのか?
- ボタン一つで作れるEC2は画期的だった
- Dockerが広がってきたが、EC2インスタンスを使うことが増えてきた
- containerによって、マイクロサービスの構築が簡単になった
- Applicationをスケールさせながら利用していくことを用意にする方法が必要になった
- だからECSが作ろうと思いました
- ECSはオーケストレーションをすることができてるので、スケールが簡単、パフォーマンスがでる、などいいこといっぱい
- Controll PlaneがECSがやってくれるので管理楽
- k8sでできることはできるようにAWSが構築していきました
- ただ、clusterの管理はk8sと同様に問題がありました
- Data Planeがあったからです
- hostで必ず管理しなければいけないものがあったのです
- つまり, Docker engineのためにライブラリやバージョンなどをしなければいけなかった
- そういうったhost上で管理しなくては行けないものは、単にシステムが動いていくためだけに管理しなければいけないもの
- それ以外にも管理しなければいけないものとしては、osのパッチ、セキュリティパッチ、インスタンスのスケーリング、などがあったが、なかなか大変なものです
- ということで、とにかくコンテナがそのまま自走してほしい、スケーラビリティなどを気にしたくないということをユーザーは求めていた
- そこで、Fargateが発表になりました
- 全ての管理面をやってくれるのが、Fargateです
- ECS上で使ってるAPIはFargateで使える
- EKSでもFargate使えるように今年動いていくよ
基本
- ECSとk8sは似てる
- Task ≒ Pod
- difinitionの設定
- これはjsonでコンテナの記述をする
- そこでtaskの定義を登録するとインスタンスの実行をする
- 今現在はFargate or EC2モード選んで実行する
- difinitionの設定
- cluster ≒ cluster
- k8s同様、clusterという概念がある
- 論理上、clusterはAggregaterとしての役割を受け持つ
- cluster内のApplicationはお互い相関関係を持っている
- 具体的には、リソース、IAMをシェアしている
- しかし、これだけでは事足りないのでApplicationサービスの抽象化が必要
- Service ≒ Service?
- 複数のtaskから成り立っている
- ELBからできている
- Task definition
- Applicationのバージョンを含んでいる
- 一つの中に複数の情報が入っているということになる
- シングルタスクのdifinitionは10のtaskまで持つことができるが推奨してない
- task difinitionの中にはnameやイメージがあるのか、など情報があるので確認していきます
- レジストリ: ECR, Other Repositories
Fargateの中でどのようにプロビジョニングがされるか
- 強み:本当に必要なリソースのみを割り当てる事ができる
- コンテナ内でリソースのかなり細かい設定ができる↓のように
- "cpu" : 1 vCPU = 1024cpu-units
- "memory": 2 gb
- 価格:
- 実は先程の細かい設定が価格に影響が出るようになる
- Taskの設定によって価格が変わる!
- おすすめ:価格の比較はtaskとマシンという比較をしないほうがいい。クラスタ単位で見たほうがいいよ
- networking
- VPCを導入している
- 全てのTaskにENIがつくようになっている
- ENIに他のエンティティが紐づくようになっている
- task定義に networkMode: "awsvpc" を指定すれば、Taskのnetworkingになる
- どのSubnetsを使いたいかを指定する必要がある
- Internetアクセスはどうやっている?
- e.g. image pullしたい! / cloudwatchにlog をpushしたい!という場合
- 2つのモードがある
- Taskがprivate subnetにある
- Taskがpublic subnetにある
- VPCの視点から見てみる
- private subnetにあるtaskがいる
- ↑が外部internetに到達したいという場合どうするか
- =NAT Gatewayが必要になる
- Internet Gateway → NAT Gateway → Route Tables → NAT Gateway → Subnets → Route Tables → Task
- NAT Gatewayのpublic IPを複数つけたい事がある場合は?
- public task setup
- taskがpublicである場合、もちろん外から利用ができる
- 説明では、public subnetにあるものとする
- public subnetの場合には、「internet gateway - ENI(Public IP)」で通信する
- ELB
- ELBの設定をするためになにを決める必要がある?
- portmappingは基本的にはコンテナにはどのportをexposeするか次第
- どのポートを通って、どのコンテナにポーティングするか、ということを決める必要がある
- どのコンテナにルーティングされる?
- targetGroupArnというものがある
- 最大100のサービスまでトラフィックを分けることができる
- ELBをserviceにアタッチするとき、
- public subnetに作り(public IPが振られる)
- ENIにポートフォワードして渡す
- PrivateLink Endpoints
- Storage
- FargateTaskを扱う時、ホストはないので書き込みは発生しない
- ただ、2つの方法でストレージにアクセスできるようになっている
- No.1 Docker Writable Layer
- Docker Imageは階層になっている
- どのコンテナでも共通だが、一番上のLayerがWritable Layerとなっている
- Task毎に10G相当のLayer Storageが使えるようになっている
- Shard Storageではないので注意
- 揮発性なので、Taskが終了すると全て消えます
- No.2 Volume Storage
- 1Task 4G相当のStorageが用意されている
- shard Storageになっている
- IAM Permissions
- Fargate / ECS Taskに紐付けられる
- Log configration
- k8sと同様
- cloudwatchに送るようになっている
- awsのlogs group
- Other
- DataDogは Fargateの利用にいち早く手を上げてくれたよ
- DEMOにDataDogの設定の仕方がある
- Security
- セキュリティに興味ある、必要があるならFargateはおすすめ
- どういったものがあるか
- host触らなくていい
- カーネルに対してもアクセスできないので、誤ってそういう操作することもなくなる
- 更には、VPCのフローログが使えたりするので様々なセキュリティメリットが有る
- CI/CD
- Netflixのようなスピード早い企業は Renovationのスピードは
440倍
早いと言われている - 更にはデプロイ数は 46倍
- 44%より多くの時間を新しいコーディングなどに当てることができるようになっている
- ECS/EKS導入するときは「Deployment」を是非検討してみてください
- 例えば、Infra as CodeのためのCDKなどの用意がありますよ
- CDK(β版)を使えばTypescriptで8行くらいでできるようになりますよ
- Netflixのようなスピード早い企業は Renovationのスピードは
- 重要なMessage
- EC2とFargateどちらを使うか並んでるなら、Fargateを使うようにしてください
- ベストプラクティスはFargateなので
======================
haraさんによる secrets のデモ
今まで
- 1. secretsないときはjsonに
- 2. kmsを使って暗号化したものをs3において〜みたいなことをやった
使い方
- SSM > Paramstore or secrets Manager
- ↑に値を置く
- arnをタスク定義に渡しておくと、自動的にコンテナの中で変数として渡される
- ↑paramが見れるかどうかはIAMで管理できる!!
======================
新しい子達
Cloud Map
- サービスディスカバリの理解の前に、マイクロサービスがいかに複雑化を理解する必要があります
- サービスディスカバリ
- 持っているサービス、プロバイダのlocationを探す
- locationというのは時にはIPで示されているかもしれない
- IPでなくても、ログと言う場合ならS3bucketとして表すこともあります
- 現在2つの一般的パターンがあります
- Sever side サービスディスカバリ patten
- 通常は、LB + Service Registry
- 全てのコネクションがLBを利用することでLatencyが増える
- ただ、ディスカバリというのは抽象化されているということなので、実際のエンドポイントを知ってる必要はなく、
- LBのエンドポイントだけわかっていればいい
- Client side サービスディスカバリ patten (最近一般的)
- これは、サービスプロバイダがServiceRegistoryに登録しておく必要がある
- clientが直接ServiceProviderにリクエストします
- それぞれで直接通信をするので、Latencyが発生することがないので良いパターンと言えます
- コンポーネントが少なくなる
- しかし、2つトレードオフの問題がある
- クライアント自身がレジストリを認識してなきゃいけない
- LBを実装してないので、ロードが長いプロバイダがあった場合、その振り分け制御はクライアント自身がやらなければいけない
- ただ、今はこの話じゃないので一旦おいておく
- リソースをダイナミックにマッピングする
- cloudのmapということで、いかなるAWSサービスもマッピングされています
- レジストリの中にあるオブジェクトには namespaceが割り当てられている
- Seviceもあるし
- Service Instanceもある
- CloudMapを使うとDNSをつくっている場合、いいことがあるらしい(聞き取れなかった)
- AZをUSのどこどこ、というふうにTagをつけると絞り込みもできるよ
- ECS, App Mesh, EKSにも対応している
- ECSのサービスディスカバリはいいいみでユーザーが意識することはない
- プロパティ毎にシステム側で管理をしてくれる
- Tokyoリージョンもちゃんとあるよ!
AppMesh
- そもそもなぜ、このサービスが必要になったのか
- モノリシックアプリが始まりだった
- これは概念的にもわかりやすいものである
- チームがFeatureを切って、デプロイする、という流れでやっていくよね
- モデルとしてもものとしてもわかりやすいものですよね
- ただ、短所としてはFeature数、チームメンバー数が増えてしまうと途端に非効率なモデルになってしまいます
- そこで、機能の境界で別のApplicationとして分けていくようにしました = マイクロサービス
- こうすることで、お互いが独立した形で管理ができるようになりました
- Developerの負担や複雑さも緩和されますし、チーム構成も少人数で行ける
- 最大のメリットは、別の環境として作ることができること
- 発想自体はよかったけど、運用側に複雑性のせいで相当な負荷を強いることになってしまいました
- デプロイの管理、構成の管理をするインフラチームは負荷増大でこれはきつい
- で、これまではシンプルでわかりやすかったのに、マイクロサービスで管理が大変になってしまいした
- では、どうやって管理をしていきましょうか?
- そこで, 一つのやり方としてApplicationコードの中に Monitor, Routing, Discovery, Deploymentなど全て含めてしまう方法がある
- ただし、複数の開発言語を網羅していくことには変わりない
- こういった環境でも一貫性を保つ必要がある = モイラーコード(一時しのぎ用)が必要になる
- じゃあ他の方法はないの?
- SideCar Proxy
- いろんなロジックが必要になりますが、一旦それをマイクロサービスの外側に置く
- 同じように必要なものに関しては、同じサイドカーを参照させればいいだけになる
- で、その結果、Applicationのデプロイとは別離 →コンフィグが聞くようになる →不備があった時、影響は最小限になるし一貫性がでる
- なぜsidecar proxyが推奨されるかは、「ベストプラクティスを踏襲してる」「開発者の負担が減る」「実際のプロセスと切り離して管理できる」ため
- ではServiceMeshはなぜ必要になったのか
- AppMesh はApplicationレイヤーの外側にある
- 内部にEnvoyを利用している
- 更にもう一点考える点がある
- どのようにして、数千コンポーネントあるような場合どのようにしていけばいいのか
- Control plane
- ServiceMeshのControl planeは様々なものに使うことができる
- AppMeshのなかではside proxyの全てをコントロールすることができる
- AppMeshはもうすぐGAでローンチされることになります
- Applicationの一元化されたログを指定の場所に送ることができるようになります
- また、ルーティングのコントロールもすることができるので、Application同士の通信の制御もできるようになる
- 様々なコンテナサービスを横断的に対応している
- Virtual Node
- 全てのApplicationの全てのバージョン1つ1つ
- Route
- Service A と Sevice Bが通信できることを制御する機能
- 注意:スライドの2つ目の文、「Virtual Node」はバージョンに基づいている
- 指定するrouteによって、どのくらいの割合で使われるかが決まる
Firecracker
- AWSがRe:Inventのなかで反響があったやつです
- OSSです
- コンテナとかcomputerサービスの効率を上げるものです
- Hypervisor上にあるフルのゲストOSに比べるとリーンなものになっている
- ミニマムデバイスモデルを採用
- カーネルのローディングをスピードアップすることができる
- メモリのフットプリントもかなり最小化されている
- いずれかFargateのバックエンドやLambdaでこれを使うようになると思います