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
70
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.4k
Kubernetesモニタリングのベストプラクティス_JAWSDays2021_20210320
kaojiri
0
870
JAWS-UG_SAITAMA_20190420
kaojiri
1
190
OpsJAWS-JAWSUG-KANAZAWA_20181123
kaojiri
1
260
AWS Systems ManagerとAWS Configのちょっといい話
kaojiri
3
1.6k
組織を意識したAWS構成管理プロセスを考える_20180112
kaojiri
0
710
JAWS Days2017 EXCEL構成管理からの脱却と次世代MSPとDevOps 2.0 by OpsJAWS
kaojiri
0
1.7k
OpsJAWS#7 20160729 SIerにおけるDevOpsの現状 ~terraformを使ったAWS開発~
kaojiri
1
1.1k
OpsJAWS#5 20160420 背伸びをしないAWS構成管理
kaojiri
0
2.8k
Other Decks in Technology
See All in Technology
AOAI Dev Day LLMシステム開発 Tips集
hirosatogamo
15
3.8k
サービスの持続的な成長と技術負債について
siva_official
PRO
10
4.4k
AWS IAMのアンチパターン/AWSが考える最低権限実現へのアプローチ概略(JAWS-UG朝会#59資料改修20分版)
htan
0
330
「我々はどこに向かっているのか」を問い続けるための仕組みづくり / Establishing a System for Continuous Inquiry about where we are
daitasu
0
170
Luupの開発組織におけるインシデントマネジメントの変遷 ver.RoadtoSRENEXT2024
grimoh
1
270
DevIO2024_レガシー運用からの脱却 -クラウド活用の実践事例とベストプラクティス-
jun2882
0
210
DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern
urmot
4
390
開発生産性をむしろ向上させる セキュリティパートナーの作り方 / Dev Productivity Con 2024
flatt_security
0
380
初中級者用如何使用backlog -VALE TUDOEDITION-
in0u
0
140
Matterport を使ってクラスメソッド各拠点のバーチャルオフィスツアーを作成してみた
wakatsuki
0
160
楽しくGoを学び合う、LayerXの勉強会文化 / LayerX's study culture of having fun and learning Go together
ar_tama
2
350
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
Featured
See All Featured
In The Pink: A Labor of Love
frogandcode
139
22k
Rails Girls Zürich Keynote
gr2m
93
13k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
Why Our Code Smells
bkeepers
PRO
332
56k
Side Projects
sachag
451
42k
Designing Experiences People Love
moore
136
23k
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Designing the Hi-DPI Web
ddemaree
276
34k
YesSQL, Process and Tooling at Scale
rocio
166
14k
Art, The Web, and Tiny UX
lynnandtonic
291
20k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
A Philosophy of Restraint
colly
200
16k
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???って言われても出してくる可能性あり • 権限周りは要勉強
ご清聴ありがとうございました