【概要】

2019/3/13 (水)に↓のセミナーがあったので行ってきました。

Build with Containers! - AWS で構築する実践的コンテナワークロード
https://pages.awscloud.com/BuildwithContainerseminar20190313-jp.html

そこでの内容をメモった内容をそのままアップしますー。

【注意】

メモをそのまま載せてるだけなので、誤字脱字があります
書ききれてないところとかは私の英語力や理解力が低かった結果です
後日スライドが共有されるそうなので、追記します
後日内容の深掘りをしていこうかとは思ってます
正直、理解できてないことも多いです

===========

【イベントメモ】

k8sについて

なぜコンテナ？

どの環境でもちゃんと使えなきゃだめだよね
フェーズなのか、どこでそれを実行するのかということも気にしなきゃいけない
また、各環境でのマシンのversionは？それのせいで上手くいかないこともあった
コンテナはマシンに関係なく、コードやエンジンなどを全て一つのパッケージにしてくれるから気にしなくて良くなる！
containerはDockerが出てから初めて一般大衆も使えるようになったね
Dockerは→２つが重要「作ったイメージは不変なものである」「レイヤー化されているので関係されている部分だけ直せばいい」

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で割り当てる
- ２つのパラメータをコンテナに設定できる
  - 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
- 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
- EKSのConroll planeはEKS VPC上に立ち上げられる（AWSが立ち上げている）
  - controll plane用のアップグレードには２つの方法がある (最近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モード選んで実行する
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したい！という場合
- ２つのモードがある
  - 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というものがある
  - 最大１００のサービスまでトラフィックを分けることができる
- 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行くらいでできるようになりますよ
  - https://github.com/awslabs/aws-cdk
重要な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として表すこともあります
- 現在２つの一般的パターンがあります
- 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の全てのバージョン１つ１つ
Route
- Service A と Sevice Bが通信できることを制御する機能
- 注意：スライドの２つ目の文、「Virtual Node」はバージョンに基づいている
- 指定するrouteによって、どのくらいの割合で使われるかが決まる

Firecracker

AWSがRe:Inventのなかで反響があったやつです
OSSです
コンテナとかcomputerサービスの効率を上げるものです
Hypervisor上にあるフルのゲストOSに比べるとリーンなものになっている
ミニマムデバイスモデルを採用
カーネルのローディングをスピードアップすることができる
メモリのフットプリントもかなり最小化されている
いずれかFargateのバックエンドやLambdaでこれを使うようになると思います

「Build with Containers! - AWS で構築する実践的コンテナワークロード」の私的イベントメモ

【概要】

【注意】

【イベントメモ】

k8sについて

なぜコンテナ？

container をオートスケールさせるときは？

CNCF

k8s細かく見ていこう

構成

haraさんによるマイクロサービスのデモ

Live

コマンド一覧

ECS のセッション

AWS Fargate

なぜFargate作ったのか？

基本

Fargateの中でどのようにプロビジョニングがされるか

haraさんによる secrets のデモ

今まで

使い方

新しい子達

Cloud Map

AppMesh

Firecracker