Terraform×AWS×Kubernetesを 駆使したサイト基盤構築に初心者が挑む July Tech Festa 2019 オイシックス・ラ・大地（株） 青木 芽衣

初心者の定義 ● AWSを触ったことがない ○ 某国産クラウドをGUI操作したことはある ○ 8月まで (前職) はオンプレの構築ばかりしていた ● Terraformも触ったことがない ● Kubernetesは独学習得を試みたが、断念した過去がある 2

● はじめに ○ 背景 ○ 本プロジェクトにおける目標 ● システム構成 ● 躓いたこと ○ Kubernetes編 ○ Terraform編 ○ AWS編 ○ その他ご紹介 ● 学び ● まとめ Agenda 3

背景 〜オイシックス・ラ・大地 という会社〜 三社合併や会社買収による事業拡大 コーポレートサイトもきちんと運用したい 4

三社合併や会社買収による事業拡大 コーポレートサイトもきちんと運用したい 基盤：X社サーバ 運用：ベンダA 基盤：Y社サーバ 運用：ベンダB 基盤：Z社サーバ 運用：ベンダC 基盤：X社サーバ 運用：ベンダE 基盤：W社サーバ 運用：ベンダD 5 背景 〜オイシックス・ラ・大地 という会社〜 Oisixサイトに 含まれている

三社合併や会社買収による事業拡大 コーポレートサイトもきちんと運用したい 6 インフラ基盤も運用する人もバラバラ 不具合の発生・復旧へのスピード感の低さ ↓ SREチームでインフラ基盤をまとめて運用したい 背景 〜オイシックス・ラ・大地 という会社〜

まず最初に考える構成 - インスタンス単位 7 Route53 Cloud Front ALB Aurora EFS

まず最初に考える構成 - インスタンス単位 8 アクセス数がそれほど多くないコーポレートサイト いざ負荷が高くなり、ダウンした時の対応は大変 Route53 Cloud Front ALB Aurora EFS

Kubernetes(EKS)導入 9 Route53 Cloud Front ALB EFS Aurora

Kubernetes(EKS)導入 10 Route53 Cloud Front ALB EFS Aurora アクセス集中時の対応はKubernetesにおまかせ

本プロジェクトにおける目標 複数のコーポレートサイトのインフラ基盤を構築し、 SREチームでのインフラ運用を実現化する 実現方法 ● AWSリソースはTerraformを使って構築 ● コーポレートサイト部分はKubernetesのマニフェストを使い、 EKSを基盤に構築 ● サイトにはWordPressを使用 ○ WordPressの機能の動作確認は実施する 11

Terraformで作成するAWSリソース 12 その他 ・CloudWatch ・CloudTrail ・S3 Bucket ・Cognito 　　など Route53 Cloud Front ALB EFS Aurora

EKS内部構成 13

初心者が躓いた点 Kubernetes (WordPressとの組み合わせによるもの) ● WordPressの管理者画面を開いたら速攻でログアウトさせられた Terraform ● いつの間にかterraform plan で差分が出ていた AWS (EKS) ● kube2iamで遊んでみたらEKSがおかしくなっていた 14

事象：WordPressの管理者画面を開くと速攻でログアウトさせられる Kubernetesで躓いたこと ログイン 数秒後 15 cookieが保持されていない！？

WordPress管理画面のログイン/ログアウトループ 16 仕組み： 　・複数コンテナが動作中 Cookie XXXXXXX 生成 Cookie YYYYYYY 生成 　・認証用ユニークキー(WordPressの設定)を元に 　　WordPress内で暗号化されたcookieを生成している

WordPress管理画面のログイン/ログアウトループ 原因： 　WordPressコンテナへの設定漏れにより、 　複数のPodが異なるcookieを生成したため、 　何度もログイン画面へリダイレクトさせられた。 対策： 　WordPressの認証用ユニークキーを設定し、複数のPodに同じ 　認証用ユニークキーを持たせ、同じcookieを生成させるようにした 17

Terraformで躓いたこと 事象：何もコードを変更していないのに、 　ある日 terraform plan をしたら差分が出ていた # module.eks.aws_launch_configuration.workers[0] must be replaced +/- resource "aws_launch_configuration" "workers" { 〜略〜 iam_instance_profile = "xxx-eksxxxxxxxxxx" ~ id = "xxx-eks-wgxxxxxxxxxxx" -> (known after apply) ~ image_id = "ami-yyyyy" -> "ami-zzzzz" # forces replacement 〜略〜 18 Launch Configurationで指定するAMI IDに差分

いつの間にかEKSのAMIに差分が出ていた 仕組み： 　EKSワーカーノードの作成にはTerraform公式モジュールを利用している 　新しいAMI がリリースされたことで、 　Launch Configurationで指定するAMI IDも新しくなった 　terraform apply してもKubernetes 環境に影響なし 19

いつの間にかEKSのAMIに差分が出ていた 対策： 1. terraform apply　→　Launch Configurationの更新 2. ノードを kubectl drain していく（クラスタから切り離す） ○ 新しいノードではAMIが新しいものに切り替わっていく 20

実際にdrainして気づいたこと 古いノードのdrain後は放置で良い drainしたノードは自動的にTerminateされる 21

AWS (EKS)で躓いたこと 　kube2iamという単語を知り、勉強しようと思った 　↓ 　結局よくわからなかったし、今回は不要なので削除した 22 　↓ 　よくわからないままとりあえず動かしてみる 　↓ 　ALB Ingressを作成・更新できなくなった 経緯と事象： Pod毎にIAMロールを 割り当てることのできる機 能

AWS (EKS)で躓いたこと 23 　kube2iamという単語を知り、勉強しようと思った (使うなら本番環境) 　↓ 　結局よくわからなかったし、今回は不要なので削除した 　↓ 　よくわからないままとりあえず動かしてみる in本番環境 一部引き渡し済 　↓ 　ALB Ingressを作成・更新できなくなった 経緯と事象：

kube2iamを削除したらEKSが正常に動作しない 原因 (明確にはわからなかったが)： ● Credential関係のエラー ● マウント失敗のログ kube2iamを削除した際にマウントされていたConfigMapが消滅 マウント関係のエラーは中身まで確認できず、お手上げ 対策： 　ノードをdrainし、新しいノードと入れ替えることで、 　稼働中のサイトを止めることなく回復 24

その他の躓き ● kustomize のoverlays の機能（基本） ● マニフェストはenv以外で変数を呼び出せない ● CPU, メモリリソースやReplicaSet の調整（基本） ● HPA(HorizontalPodAutoscaler) の調整（基本） ● jobを使用したAuroraへのDB・ユーザ作成 ● tf ファイル内の配列はアルファベット順に書かないとAWSでの設定が同じ でも差分が出る ● CloudWatchで取得するPodのログストリーム名を、Pod名ではなくPodの 役割で設定したい ● WordPressの予約投稿に失敗する ● WordPressでのメディアアップロードサイズの上限を上げたい など 25

学び ● 勉強＆実践してみて ○ AWSとTerraformはセットで勉強すると身に付く ○ Kubernetesのメリットを実感 ● プロジェクトを通して（当然ですが） ○ 本番環境で勉強をしない（せめてテスト環境） ○ 躓きを経験することで新しいノウハウを得ることができる ○ 更にアウトプット（言語化）することで理解が深まる 26

まとめ 本プロジェクトの目標 TerraformでAWSリソースを作成し、 Kubernetesで複数コーポレートサイトのインフラ構築・運用を実現する 初心者(発表者)が特に躓いた次の点について紹介した ● WordPressの管理者画面を開いたら速攻でログアウトさせられる ● いつの間にかterraform plan でEKSのAMIに差分が出ていた ● kube2iamを削除したらEKSが正常に動作しなくなった(本番環境) 27

謝辞 TerraformもAWSもKubernetesも初心者であった発表者は とあるチームメンバーのご指導により超短期間で ここまで成長することができました（まだまだ未熟ではありますが） 大変感謝しております ご清聴ありがとうございました 28