Upgrade to Pro — share decks privately, control downloads, hide ads and more …

EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely

206cd98801e9ad1a1a246da5f3b5a40b?s=47 ykoma
May 24, 2019

EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely

206cd98801e9ad1a1a246da5f3b5a40b?s=128

ykoma

May 24, 2019
Tweet

Transcript

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

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

  3. 駒原 雄祐 •サイバーエージェント メディア統括本部 広告Div所属 Amebaをはじめとした自社メディアのアドテクノロジーを活用し たマネタイズがミッション Ameba Infeedの立ち上げ・開発・運用 昨年までAbemaTVの広告配信システム刷新にも参画

    •現在のミッション 初期開発から4年以上経過し、カオス化が進んだAmeba広告 システムのインフラ環境を、EKSをベースとした新環境にリプ レース
  4. Ameba Ads 2.0 自社メディア向けのネイティブ広告「Ameba Infeed」 外部媒体向けに入札して配信可能な「Ameba DSP」 メディアの持つ会員データ、行動データなどを最大限に活用した 配信に強み

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

  6. Ameba広告システム規模 •150,000+ RPS 配信面からの広告リクエスト、計測リクエスト SSPからのbidリクエスト 運用管理画面からのAPIリクエスト etc … •50+ Micro

    services 運用開始から丸4年以上が経過 モジュールや機能が大量に追加 (運用開始当初は両手で足りる程度だった)
  7. 課題 •2個のAWSアカウントに跨っている 歴史的経緯 (開発体制が2部署に分かれていた) 構成の違い •アーキテクチャがバラバラ マイクロサービスごとに担当チームの慣れた手法 多くのアーキテクチャの混在 運用負荷高 人材流動コスト高

  8. インフラ刷新計画 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
  9. Why EKS ?

  10. EKS •Amazon Elastic Container Service for Kubernetes •AWSが提供する「マネージドKubernetesコントロールプレー ン」 masterノード、Etcdなどの面倒をAWSが見てくれる

    masterノードのマイナーバージョンアップはAWSが適用してく れる ClusterRoleとIAMロールやIAMユーザとの連携
  11. EKSとは? •Workerノードは自前で構築・管理する必要あり IAM、Security Group、AutoScaling Groupなどを用いて、 自前でEC2インスタンスをWorkerノードとして起動する

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

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

  14. EKSとIAMロール

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

  16. IAM User と IAM Role •IAM User キーとシークレットの文字列の組み合わせで認証する方式。 IAM Userに紐付けられたPolicyに沿って、AWSリソースに対してアクセスが可能。

    【メリット】 AWSの外からも簡単に利用できる 【デメリット】 アプリケーションから使用する際に、キーとシークレットをソースコード上やconfigファイル等にべた書きさ れることが多く、流出によるセキュリティリスクをはらむ。
  17. 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
  18. EC2とIAM Role この状態を 実現したい EC2 for App X EC2 for

    App Y DynamoDB X S3 Y
  19. 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
  20. 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
  21. 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
  22. 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
  23. Kiamの導入 〜そして令和へ〜

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

  25. 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と通信 してセッション情報を取得
  26. KiamをEKSに導入。しかし… • Helm Chartが公開されているのでサクッと入れてみる ◦ https://github.com/helm/charts/tree/master/stable/kiam 動かない・・・ しかし・・・

  27. KiamをEKSに導入。しかし… • Helm chartのデフォルト状態では、Kiam ServerもKiam AgentもただのDaemonsetと してWorkerノードにapplyされる • しかし、Kiam Serverは、masterノードで動

    かすことが想定されている ◦ ServerとAgentのPodが同一ノード上にい ると、iptablesの競合で動作しない ◦ EKSはmasterノードがマネージドサービス として隠蔽されている 詰んだか…
  28. 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
  29. 他にも踏んだ罠の数々 時間の関係で割愛 もし興味があれば 懇親会で話しかけてください

  30. まとめ

  31. まとめ • アプリケーションからAWSリソースにアクセスするときは、 IAM UserよりIAM Roleを • KubernetesでIAM連携するためにKiamを導入 ◦ Kiamを使うとPodレベルでIAM

    Roleを割り当てられる • EKSに導入するときにはKiam Serverを専用ノードに • 形ができたときには令和になってた
  32. おまけ (ECSの場合) • ECSにはTask (コンテナ) 単位でIAM Roleを割り当てる機能 がネイティブに提供されている ◦ https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task-iam-

    roles.html Amazonさん、EKSでもIAMのネ イティブ対応お願いします!
  33. ご清聴ありがとうございました