Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AWS SummitTokyo2019-reCap_20190620
Search
kaojiri
June 20, 2019
Technology
1
81
AWS SummitTokyo2019-reCap_20190620
AWS Summit Tokyo2019の振り返りと、Container Insightsの紹介です。
kaojiri
June 20, 2019
Tweet
Share
More Decks by kaojiri
See All by kaojiri
コンテナ監視って何見るの?~初心者編~
kaojiri
8
5.9k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
1.1k
JAWS-UG_SAITAMA_20190420
kaojiri
1
200
OpsJAWS-JAWSUG-KANAZAWA_20181123
kaojiri
1
310
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.7k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
800
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.9k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.3k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
3k
Other Decks in Technology
See All in Technology
kintone開発チームの紹介
cybozuinsideout
PRO
0
73k
あとはAIに任せて人間は自由に生きる
kentaro
3
1k
datadog-distribution-of-opentelemetry-collector-intro
tetsuya28
0
220
Claude Code x Androidアプリ 開発
kgmyshin
1
490
歴代のWeb Speed Hackathonの出題から考えるデグレしないパフォーマンス改善
shuta13
6
570
リモートワークで心掛けていること 〜AI活用編〜
naoki85
0
200
R-SCoRe: Revisiting Scene Coordinate Regression for Robust Large-Scale Visual Localization
takmin
0
360
AI時代の大規模データ活用とセキュリティ戦略
ken5scal
1
280
AIが住民向けコンシェルジュに?Amazon Connectと生成AIで実現する自治体AIエージェント!
yuyeah
0
240
ECS モニタリング手法大整理
yendoooo
1
110
夢の印税生活 / Life on Royalties
tmtms
0
270
Gaze-LLE: Gaze Target Estimation via Large-Scale Learned Encoders
kzykmyzw
0
300
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.5k
4 Signs Your Business is Dying
shpigford
184
22k
A better future with KSS
kneath
239
17k
Adopting Sorbet at Scale
ufuk
77
9.5k
Typedesign – Prime Four
hannesfritz
42
2.8k
Site-Speed That Sticks
csswizardry
10
780
Build your cross-platform service in a week with App Engine
jlugia
231
18k
For a Future-Friendly Web
brad_frost
179
9.9k
Optimising Largest Contentful Paint
csswizardry
37
3.4k
How STYLIGHT went responsive
nonsquared
100
5.7k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Transcript
AWSSummitTokyore:Cap コンテナ周りのセッション所感と ContainerInsightsの紹介 2019/06/20 @AWSLoftTokyo
Agenda 1. AWSSummitTokyo所感 • 全体感 • おすすめセッション 2. 気になる機能紹介 •
ContainerInsights • 気になること
1.AWSSummitTokyo所感
全体所感 • エンタープライズ感 • 革新的な破壊的機能というよりは、これから始めるレイトマジョリティ向け な雰囲気を感じた • いよいよボリュームゾーンの闘いに突入する予感? • コンテナ、Kubernetes周りの機運の高まりを実感
• エンタープライズ感とは真逆だが、コンテナ周りのセッションの人気たるや • いよいよ日本でもKubernetes本番事例やTipsが出回り始めた • re:Inventは皆行きたがるのになぜか幕張は遠いと言われる問題…
おすすめセッション • 入門編 • C3-02:【初級】AWSコンテナサービス入門 • A3-02:KubernetesonAWS(AmazonEKS実践入門) • 実践編 •
J2-07:AWSのマネージドサービスを活かしたKubernetes運用と AmazonEKSによるクラスタのシングルテナント戦略について • A3-03:サービスメッシュは本当に必要なのか、何を解決するのか
おすすめセッション ~入門編~ • C3-02:【初級】AWSコンテナサービス入門 • これからコンテナを始めようとする方向けに、コンテナ開発に必要な要素を 洗い出した上で、AWSにおけるコンテナ関連サービスを網羅的に説明 • A3-02:KubernetesonAWS(AmazonEKS実践入門) • コンテナ動向・背景を説明のうえ、KubernetesとEKSの特徴を整理
おすすめセッション ~実践編1/2~ • J2-07:AWSのマネージドサービスを活かしたKubernetes運用と AmazonEKSによるクラスタのシングルテナント戦略について • 流石のユーザ事例セッション • SREが共通基盤を楽に運用していくために取った戦略とは? • 共通基盤といいつつ、共通ではない
• 共通SWスタックを用意し、個別に初期構築。その後のk8s運用は開発チームで • SREはあくまで最後の砦。運用代行ではないという発想 • どんなアーキテクチャも移行しやすいように設計 • あくまで部品でしかなく、常によりよいものに改善しやすいように保つ
おすすめセッション ~実践編2/2~ • A3-03:サービスメッシュは本当に必要なのか、何を解決するのか • サービス/システムが成長・拡大するにあたり、様々な問題が発生する • ベースはALB–EC2–RDS構成 • マイクロサービス化しよう、となる •
モノリスというイメージと、マイクロサービスに期待する内容を整理 • ざっくり言えば、ちゃんとトレースしたい • X-Rayが便利 • マイクロサービスなりの課題もある • ログの統一化、パフォーマンス測定、サーキットブレーカー • 2つのアプローチ • 共通ライブラリ • プロキシ → これがいわるゆサービスメッシュ • 課題をちゃんと把握する。X-Rayで十分なケースも散見される。 • サービスメッシュまで必要になってから考える、でも十分なのでは? • 中の人らしからぬ発言でセッションが終了
7/1再演!!!! • 入門編 • C3-02:【初級】AWSコンテナサービス入門 • A3-02:KubernetesonAWS(AmazonEKS実践入門) • 実践編 •
J2-07:AWSのマネージドサービスを活かしたKubernetes運用と AmazonEKSによるクラスタのシングルテナント戦略について • A3-03:サービスメッシュは本当に必要なのか、何を解決するのか 申込サイト:https://awssummittokyoosakatechrecap1.splashthat.com/
2.気になる機能紹介
ContainerInsights
の前に…
Kubernetesってご存知ですか?
Kubernetes 超ざっくり • コンテナオーケストレーションツールのひとつ • 全体は非同期分散処理システム • 色々なコンポーネントがそれぞれの役割を全うすることで全体を構成 • マイクロサービス??? •
詳細は割愛 • ControlplaneとDataplane • それぞれはN台のサーバでクラスター構成 • Controlplane:マスターデータストア、制御関連 • Dataplane:実際のコンテナ(Pod)が配置されるエリア • kubectlコマンドで操作 • k8s版awscliみたいなもの • ノードを表示する例:kubectlgetnodes • Podを表示する例:kubectlgetpod
ElasticContainerServicefor Kubernetes(EKS) • K8sのControlplaneがマネージド • Dataplane • EC2 • EKS用のAgentが入っている以外は普通のEC2(ざっくり)
• 自分好みにどうぞ • Fargate • 2019年中に対応予定
ElasticContainerServicefor Kubernetes(EKS) Dataplane ノード ControlPlane Scheduler APIServer coredns ノード ノード
controller kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにDataplaneの各種リソースを管理 etcd kubectl クライアント K8sクラスター K8sリソース管理 (作成、変更、削除、検索など) ここがマネージド
ContainerInsights
ContainerInsights概要 • KubeConEurope2019でプレビューリリース • Kubernetesクラスター内で動くリソース状況を可視化する機能 • 今までは取りたければ独自で導入・設定が必要だった • Pod,Namespace,Serviceなどの単位で集約したメトリクス可視化 •
ログ管理の機能も併せて提供 • AWS公式の安心感 • 独自の仕組みを維持・運用しなくていい • CloudWatchアラーム連携できるのが嬉しい • 控えめに言って良い • 最初はいらないでしょって言ってたのにだしてきた • 3/13BuildwithContainers!@AWSでYanivに聞いて、 “Ha??”って言われたのに…
ElasticContainerServicefor Kubernetes(EKS) Dataplane ノード ControlPlane Scheduler APIServer coredns ノード ノード
controller kubelet kubeproxy kubelet kubeproxy kubelet kubeproxy Pod(Container) etcdの情報をもとにDataplaneの各種リソースを管理 etcd kubectl クライアント K8sクラスター K8sリソース管理 (作成、変更、削除、検索など) この辺のメトリクス収集が可能になった
ContainerInsights仕組み • CloudWatchAgentコンテナをDaemonSetで動かす 1. 同一ノード上の他Podの情報を取得 1. ログはFluendDのPodで、ホスト側のボリュームをマウントしている 2. 取得した情報(やログ)をCloudWatchへ転送 ノード
ノード ノード CloudWatch ServicePod CloudWatchAgent(FluentD)DS ① ① ① ②
ContainerInsights有効化する手順 • IAMRoleにポリシーアタッチ • CloudWatchAgentServerPolicyを忘れずに • Namespace、サービスアカウント作成 • Config作成し、ConfigMapとして登録 •
クラスター名、リージョン、取得間隔、送信間隔 など… • DaemonSet起動 ContainerInsights有効化手順: https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/deploy-container-insights.html
ContainerInsights有効化する手順 # Namespace作成 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cloudwatch-namespace.yaml kubectl apply -f
cloudwatch-namespace.yaml # サービスアカウント作成 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-serviceaccount.yaml kubectl apply -f cwagent-serviceaccount.yaml # ConfigMap設定、適用 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-configmap.yaml <設定変更 → とりあえずクラスター名だけ設定すれば動く> kubectl apply -f cwagent-configmap.yaml # Daemon Set起動 curl -O https://s3.amazonaws.com/cloudwatch-agent-k8s-yamls/kubernetes- monitoring/cwagent-daemonset.yaml kubectl apply -f cwagent-daemonset.yaml K8sへの操作
ContainerInsightsイメージ
ContainerInsights気になること CloudWatch価格:https://aws.amazon.com/jp/cloudwatch/pricing/ 規模感:116*0.3=$34.8 クラスター=1、Namespace=4 ノード=2、Service=1、Pod=2 ・ログとしても送信される CloudWatchLogsにもパフォーマンスデータが送信されるので注意 → GBあたり0.76USD ・カスタムメトリクス扱いになる。ノード、Service、Pod辺りが増えやすいので規模感を捉えておく → 最初の10,000メトリクス
0.30USD CloudWatchLogsとしてもメトリクスデータ を送信している 特に利用予定がなければ保存期間設定は必須 ContainerInsightsで収集されるメトリクス:https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics.html
ContainerInsights気になること • 権限周り • CloudWatchAgentが他Podの情報を抜いているように見える • ノード側でDockerstatsコマンドみたいなのを叩いているような印象だけど、どうやってる? • FluentDは、ノード側でrootしか参照できないファイルを参照しているように見える •
ホストマウント先のディレクトリは全ユーザRead権限ついているが、ファイル実体はrootしか 参照できないもの • なのになんで参照できるの? • そもそもPodが起動する権限ってなんなん? • ざっくり見るとroot権限で動いているっぽい… • この辺知っている人がいたら教えてください…
まとめ • コンテナ/EKSアツい • 進歩が速いのでキャッチアップを忘れずに • AWSサービスとしては珍しく、ロードマップが公開されている • https://github.com/aws/containers-roadmap/projects/1 •
OpsJAWSでも取り上げていきたい! • ContainerInsightsはいい • ただ、課金は意識した方がいい。他クラウドは無料だけどね…。 • Ha???って言われても出してくる可能性あり • 権限周りは要勉強
ご清聴ありがとうございました