EKSクラスタをいい感じに 作ろうとして苦労してる うちに令和になった話(前編) Yusuke Komahara オレシカナイト vol.10 2019.05.24

1.Ameba広告システムのインフラ事情 2.インフラ刷新計画 3.Why EKS ? 4.EKSとIAM Role 5.Kiamの導入 6.まとめ

駒原 雄祐 •サイバーエージェント メディア統括本部 広告Div所属 Amebaをはじめとした自社メディアのアドテクノロジーを活用し たマネタイズがミッション Ameba Infeedの立ち上げ・開発・運用 昨年までAbemaTVの広告配信システム刷新にも参画 •現在のミッション 初期開発から4年以上経過し、カオス化が進んだAmeba広告 システムのインフラ環境を、EKSをベースとした新環境にリプ レース

Ameba Ads 2.0 自社メディア向けのネイティブ広告「Ameba Infeed」 外部媒体向けに入札して配信可能な「Ameba DSP」 メディアの持つ会員データ、行動データなどを最大限に活用した 配信に強み

Ameba広告システムの インフラ事情

Ameba広告システム規模 •150,000+ RPS 配信面からの広告リクエスト、計測リクエスト SSPからのbidリクエスト 運用管理画面からのAPIリクエスト etc … •50+ Micro services 運用開始から丸4年以上が経過 モジュールや機能が大量に追加 (運用開始当初は両手で足りる程度だった)

課題 •2個のAWSアカウントに跨っている 歴史的経緯 (開発体制が2部署に分かれていた) 構成の違い •アーキテクチャがバラバラ マイクロサービスごとに担当チームの慣れた手法 多くのアーキテクチャの混在 運用負荷高 人材流動コスト高

インフラ刷新計画 AWS account X AWS account Y AWS account Z App A App B App C App D App E Before After App A App B App C App D App E

Why EKS ?

EKS •Amazon Elastic Container Service for Kubernetes •AWSが提供する「マネージドKubernetesコントロールプレー ン」 masterノード、Etcdなどの面倒をAWSが見てくれる masterノードのマイナーバージョンアップはAWSが適用してく れる ClusterRoleとIAMロールやIAMユーザとの連携

EKSとは？ •Workerノードは自前で構築・管理する必要あり IAM、Security Group、AutoScaling Groupなどを用いて、 自前でEC2インスタンスをWorkerノードとして起動する

比較対象 •kops https://github.com/kubernetes/kops Kubernetesクラスタをクラウド環境に合わせてコマンド ベースで構築してくれる コントロールプレーンからワーカーノードまで、ワン・コマ ンドで一気に構築してくれる 構築は楽だが、AWS上に作られるリソースが少しわかり にくいところが難点

EKSを選んだ理由 •AWS提供の安心感 •Etcdがマネージドで提供される ストレージ系は極力管理したくない •Fargate対応予定にも期待 •kopsと比較すると初期構築の手順は多いが、総合的に見 て、構築後の運用はEKSのほうがしやすいと判断

EKSとIAMロール

EKSを構築するにあたり •アプリケーションから各種AWSリソースへのアクセス制御を いい感じにしたい

IAM User と IAM Role •IAM User キーとシークレットの文字列の組み合わせで認証する方式。 IAM Userに紐付けられたPolicyに沿って、AWSリソースに対してアクセスが可能。 【メリット】 AWSの外からも簡単に利用できる 【デメリット】 アプリケーションから使用する際に、キーとシークレットをソースコード上やconfigファイル等にべた書きさ れることが多く、流出によるセキュリティリスクをはらむ。

IAM User と IAM Role •IAM Role EC2などのAWSリソースに対して、AWSリソースの操作権限を与える方式。 【メリット】 キーやシークレットの管理が不要なため、 ソースコード管理のミスによる流出リスクが 低減される 【デメリット】 EC2など適用可能なAWSリソースが限られて いる AWS Black Belt Techシリーズ AWS IAM より引用 https://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam

EC2とIAM Role この状態を 実現したい EC2 for App X EC2 for App Y DynamoDB X S3 Y

EC2とIAM Role EC2 for App X EC2 for App Y S3 Y DynamoDB X DynamoDB X の操作可能なポ リシーを持ってい るよ IAM Role X S3 Y の操作可能なポ リシーを持ってい るよ IAM Role Y EC2に対し、それぞれに適したIAM Roleを設定 →それぞれのRoleには、AssumeRole Policyを適切に設 定しておく IAM

EC2とIAM Role EC2 for App X EC2 for App Y S3 Y DynamoDB X IAM Role X IAM Role Y STS Assume Roleによって、セッション情報を取得 IAM sts:assume-role sts:assume-role

EC2とIAM Role EC2 for App X EC2 for App Y S3 Y DynamoDB X IAM Role X IAM Role Y 取得したセッション情報を使って各リソースにアクセス →EC2インスタンスからRoleで指定されたPolicyに沿ったアクセ ス制御ができる IAM AWS-STS

EKS(Kubernetes)の場合… S3 Y DynamoDB X IAM RoleはEC2の単位でしか指定できない →1インスタンス(Workerノード)内に複数のアプリケーションPodが 動くEKS(Kubernetes)環境ではそのまま使えない EC2 instance (EKS Worker) EC2 instance (EKS Worker) App X App X App X App Y IAM Role X IAM Role Y App Y

Kiamの導入 〜そして令和へ〜

Kiam (https://github.com/uswitch/kiam) とは •Kubernetesクラスタ内からIAM Roleを利用できるようにするOSS もちろんEKSからも利用可能

Kiamの仕組み 図はBluematadorのブログより引用 https://www.bluematador.com/blog/iam- access-in-kubernetes-kube2iam-vs-kiam ● Kiam Agent ○ Daemonset (on Worker) ○ PodのIAMへのリクエストメタデータAPIへ のリクエストをiptablesでフックしてKiam ServerとgRPC通信でRoleのセッション情 報をやり取り ● Kiam Server ○ Daemonset (on Master) ○ masterノードに強力なIAM Roleを持たせ ておく ○ Agent経由で、Podの代わりにIAMと通信 してセッション情報を取得

KiamをEKSに導入。しかし… ● Helm Chartが公開されているのでサクッと入れてみる ○ https://github.com/helm/charts/tree/master/stable/kiam 動かない・・・ しかし・・・

KiamをEKSに導入。しかし… ● Helm chartのデフォルト状態では、Kiam ServerもKiam AgentもただのDaemonsetと してWorkerノードにapplyされる ● しかし、Kiam Serverは、masterノードで動 かすことが想定されている ○ ServerとAgentのPodが同一ノード上にい ると、iptablesの競合で動作しない ○ EKSはmasterノードがマネージドサービス として隠蔽されている 詰んだか…

Kiam Server専用ノードで解決 ● Kiam Server専用のWorkerノードを用意 ○ Kiam ServerはnodeSelectorで専用ノードで動作 ○ Kiam Agentはaffinityで専用ノード以外で動作 ○ 専用ノードのEC2に、必要なすべてのRoleをAssumedできるIAM Roleを割り当て ● 注意点 ○ Kiam以外のものは、基本的にnodeSelectorなりaffinityなりを指定する必要がある (Kiam Server専用ノードで他のPodが起動しないように) Worker for Kiam Server Worker for general App A App B Kiam Agent App C App D Kiam Server IAM

他にも踏んだ罠の数々 時間の関係で割愛 もし興味があれば 懇親会で話しかけてください

まとめ

まとめ ● アプリケーションからAWSリソースにアクセスするときは、 IAM UserよりIAM Roleを ● KubernetesでIAM連携するためにKiamを導入 ○ Kiamを使うとPodレベルでIAM Roleを割り当てられる ● EKSに導入するときにはKiam Serverを専用ノードに ● 形ができたときには令和になってた

おまけ (ECSの場合) ● ECSにはTask (コンテナ) 単位でIAM Roleを割り当てる機能 がネイティブに提供されている ○ https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-iam- roles.html Amazonさん、EKSでもIAMのネ イティブ対応お願いします！

ご清聴ありがとうございました