たかぎ

## プロジェクト概要 AWSで稼働予定のサービスに対し、障害時・メンテナンス時に任意の画面を表示させる。 ## 取り組み概要 - CloudFront -> ALB -> Amazon EKSクラスタ -> Pod(nginx) 接続経路の作成 - サービスメンテナンス時はALBリスナールールを用いてCloudFrontの特定のパスへリダイレクトし、S3のアセットへルーティングする。 - サービス障害時はALBから返ってくるエラーコードで評価を行いCloudFrontからS3のアセットへルーティングする。 - チームメンバーが各々の個人環境を作成する際、AWSリソースが重複しないよう次の点で工夫。 - CloudFront、ALB、ターゲットグループ、EC2インスタンス、Route53ドメイン、Istioリソース(VirtualService)において個人の識別名(4文字以内)を含めたAWSリソースを作成。 - IstioリソースとKubernetesマニフェストファイルはAnsibleとKustomizeを組み合わせているため、Ansible内でIstioリソース(VirtualService)に記載するFQDNにダミー文字列を予め仕込んでおき、Ansible実行時に個人の識別名で置換するよう修正。 - EKSクラスタ内で検証環境を五つ作成する必要があったため、Namespaceを五つ作成し論理的なクラスタを作成。 - 作成したNamespaceへのトラフィックルーティングはistioリソースのVirtualSerivceで記載し、クライアントがアクセスしたFQDNによってどのNamespaceにルーティングするかを設定。 - CloudFront -> ALBを経由したアクセスのみ受け付ける外部ネットワーク専用のistio-ingressgatewayを作成。内部用と外部用を分割することで、アクセスできるPodの範囲を限定。上述のVirtualServiceでは外部ネットワーク専用のisito-ingressgatewayにバインドされている。 今後、CloudFrontに対しWAFを追加し、こちらもTerraformで管理する方針です。 CloudFrontおよびWAFのモニタリングはDatadogやKinesis Data Firehoseで行います。

## プロジェクト概要 - Cluster-AutoscalerによるEKSノードのオートスケール動作検証 - Cluster-AutoscalerおよびHorizontal Pod Autoscalerを組み合わせた動作検証 - AWS Node Termination Handlerを用いたスケールイン時のPod正常終了及びDraining動作確認 ### プロジェクト遂行理由 - 既存サービスへの機能追加によるトラフィック量が増大が見込まれるため、 Podの水平スケールだけでなくWorkerNodeの水平スケールも行うことで、 EKSクラスタの拡張性および柔軟性を確保する。 - WorkerNodeの水平スケールに関する知見が他プロジェクトにも無かったため、 今後のサービス拡張において有用となる実績を作る。 ## 取り組み概要 - AmazonEKSへCluster-AutoscalerならびにHorizontal Pod Autoscalerの組み込み - 上記プロダクト組み込みの際に必要となるAWSリソースの特定とTerraformコードへの落とし込み - 検証日程・検証パターンの作成、動作検証の実施 - 顧客要件に合わせたスケーリング動作のカスタマイズ - K8sのPriorityClassを用いたPodスケジューリングタイミングの調整 - AWS CLIを用いたシェルスクリプト(100行程度)を作成し、AutoScalingグループのコントロール - AWS NodeTermination Handlerの導入に併せてAutoScalingライフサイクルフック,EventBridge,SQSのセットアップ ## 取り組み詳細 - Cluster-AutoscalerとHorizontal Pod Autoscalerに与えるパラメータは各環境において異なるため、差分の吸収はAnsibleで行い、Kustomizeとkubectlで環境構築を行った。 - AmazonEKS含むAWS環境はTerraformでコード化しGitリポジトリで管理するため、動作要件の調査とTerraformコードの調査と実装は並行して行った。 - スケールイン時の動作を確認すると、ingressgatewayやアプリケーションPodが外部からのヘルスチェックに応答しない動作が見えたため、AWS NodeTerminationHandlerでNodeのTerminatingを検知し、PodのdrainとNodeのcordonを行うことで別NodeでPodを起動させ、ヘルスチェックに応答しない動作を解消。 - istio-ingressgatewayのTerminating時に確立済みコネクションの正常終了ができていない挙動を確認したため、lifecycle.preStop.exec.commandでsleepを行い、sleep後にSIGTERMをpilot-agentプロセスに送信することでタイムアウトによるHTTPコネクションエラー対策を実施。 - 検証スケジュールの作成は、機能ごとの大項目からタスクを分割し、タスクからサブタスクを作成。1サブタスクあたり2時間から4時間といった粒度で作業時間の見積もりを行い、日次で進捗報告を行う。 ## 次に活かせる学び - Cluster-Autoscalerの動作検証が行えたこと。 - スケールイン時にはPodDisruptionBudgetによるPod evictやNodeのcordon/drainなど、基本的な動作について学ぶことができた。 ## このプロジェクトを踏まえた今後について - 今後はこれらのスケーリング要素が標準になると想定しているため、次回以降は設計から担当させて頂けるよう進言し、柔軟かつ堅牢なサービス基盤の要素として取り入れていきたい。 - オンデマンドのEC2インスタンスでEKSクラスタを構築したが、スポットインスタンスの場合にはどのようなパラメータ(ツール)がありどれくらいにすると良い感じになるか？ またスポットインスタンスをEKSノードとして運用するにあたり注意点は？ といった内容についてもっと深堀する。 - アプリケーション開発者がPodに情報を持たせるconfigmapやsecretに更新があった場合にPod側の再読み込みを自動化するツールなど、監視や運用サポートツールに対する知見も積極的に吸収する。

### 担当箇所 ##### 構成管理 - TerraformとAnsibleを用いた個人開発環境、開発環境(dev)、ステージング環境(stg)、プロダクション環境(prd)の構築 個人開発環境は、開発環境と同じアカウントで作成を行いますが、個人の識別名を変数化し、terraform apply実行時に必ずユニークな文字がリソース名に付与される仕組みを採用し各個人の環境を作成します。 - AnsibleとKustomizeを組み合わせEC2インスタンスのパラメータ設定とEKS内部の構築自動化 - Amazon EKSのNamespaceとIngressGatewayによる開発環境の複数面対応 開発チームの検証環境が1つだけだと様々なバグの修正を行いテストまで完了させるためには、どうしても複数の環境が必要となりました。 Route53でサブドメインを複数作成しALBのALIASを紐付け、 istio-ingressgatewayでFQDNによるトラフィックのNamespace振り分けを採用し、 AmazonEKS内で複数の開発環境を擬似的に構築しています。 ##### Istio (Envoy-Proxy) - Istio機能検証(IngressGateway, Gateway, VirtualService, DestinationRule, ServiceEntry) IngressGatewayが何らかの原因により機能しなくなった場合を想定し、 IngressGatewayの冗長化を目的としたPodAffinityを活用し、異なるAZのワーカーノードへPodを配置する検証を行いました。 - フロントエンドからバックエンドに対する通信において、コネクション効率を考慮したEnvoy-SidecarでのHTTP1.0 < - > gRPC変換の動作検証 EKSクラスタを2つ用意し、 1つ目のクラスタ(Webクラスタ)はWebUIを提供するnginxコンテナとバックエンド連携するAPIを配置。 2つ目のクラスタ(APIクラスタ)はマイクロサービス化されたAPI群を配置。 WebクラスタからAPIクラスタ間の通信はHTTP1.0(REST)ですが、APIクラスタ側ではAPI PodのEnvoy-SidecarでgRPCへの変換を行う形での検証を行いました。 - サービス提供を行うアプリケーションPodに対しL7レベルの監視を行うため、Envoy-Sidecarでのアクティブヘルスチェック検証および実装 サービス監視手段の冗長化として、ELBからのヘルスチェックの他に、Envoy-FilterのL7ヘルスチェック機能を採用しました。ヘルスチェックの結果はPodのログに出力されるため、Datadogによるログモニタに組み込むことでアラート通知することで運用チームへの通知を行います。 ##### モニタリング - DatadogとAWSのインテグレーションとモニタリング - TerraformからDatadogで、監視定義コード化とgit管理 Terraformを使用した監視定義のコード化を行うことで、バージョン管理や他のプロジェクトでも再利用できる形にし、開発効率および運用・監視定義更新の利便性が向上されました。 ##### CI/CD - GitLab Runnerを用いたDockerプライベートリポジトリへのDocker Image Pushパイプライン構築 - デプロイフレームワークのArgoCDを用いたKubernetes環境へのデプロイ環境の構築(app of apps) 多くのアプリケーションPodのデプロイを一度の操作で行うようにするべく、 ArgoCDのApp of Appsを活用し、デプロイ時（運用時）の手順簡略化に貢献しています。 App of Appsのデプロイイメージとしては、親となるリポジトリのデプロイ操作を行うことで、 子として紐付く複数のアプリケーションコンテナが同時にデプロイされる仕組みです。 ##### その他 - Jira を用いたスクラム、チケット管理、進捗確認 - Confluenceでドキュメント類の作成、更新 - 社内Istio勉強会（資料作成、メインスピーカー） - 業務を進める上でのコミュニケーションは次の方式で行いました。 デイリースクラムで現在の担当チケットおよび進捗状況、ブロック要因の有無について連携。 簡易的な連絡はMattermostで行い、認識合わせや詳細な情報共有についてはZoomなどを活用。

## 制作目的 - 自分専用のYouTube Live番組表を表示する。 ## 画面表示概要 - テーブルに登録したYouTubeチャンネルのライブ情報およびライブが行われているかの状態を表示する。 - 現在時刻から2時間前以降の当日のライブの情報を表示する。 - ステータスは、ライブ開始前であれば「Upcoming」、ライブ中であれば「Live」を表示する。 ## 内部処理概要 - YouTubeチャンネルのIDを元に、当日に行われるYouTubeライブの時刻・タイトル情報をAPI経由で取得する。 - YouTube Data API v3を用いる。 - 情報取得は毎時10分、30分、50分に自動実行する。 ## Channel テーブルへのデータ追加手段 - 対象のチャンネル情報をCSVファイルで用意し、Django管理画面から一括追加を行う。