ID:59282さん

このプロジェクトでは、社内のチーム間で利用できる共通的な通知ツールの開発及びインフラ構築を担当しました。このプロジェクト内で取り組んだタスク別に以下に詳細を記載します。 # 担当業務 - インフラ構成の設計と構築 - インフラリソースのコード管理としてTerraformを利用 - Pythonでのコーディング( Dockerを利用した開発） - テスト - CICDの構築 - Github actions利用 - buildについはCodeBuildを利用 - Terraform Moduleの作成 # プロジェクト詳細内容 - 各AWSアカウントから利用できる共通的なSlack通知機構の構築 このタスクを進めていく上での課題として、AWS ChatBotというサービスを社内の規定により利用できないことがありました。AWS ChatBotを利用すれば簡単にCloudWatch Alarmの通知を実現できるのですが、それが利用できなかったためLambdaを作成しその中でSlack APIを叩く処理を実装するように致しました。 インフラ構成としては、SNS Topicを作成しそのサブスクリプションとしてSlack通知用のLamdbaを設定するといった内容になっております。利用する場合は、SNS Topicに対して通知先のchannel名や通知メッセージが含まれたJSONデータを送ることでSlack通知できるように致しました。 また、インフラリソースはTerraform及びCloudformation Stacksetsを利用してコード管理しました。 - より簡単に利用できるためのTerraform moduleの作成 多くのチームに上記で構築した通知機構を利用してもらうために、利用頻度の高い構築パターンのTerraform module化にも努めました。 CloudWatch AlarmをSlack通知するためのmoduleでは、通知先channel名とCloudWatch Alarm名を設定するだけで通知ができるように設計しました。その他にもCloudWatch Logsのログ監視の通知として利用できるmoduleなども作成しました。 できるだけ簡単に利用できるように設計することで、各チームの開発スピードの向上に貢献できたのではないかと思っております。 # 発揮したバリューや学んだこと - 構成の設計から実装、テスト、構築を全て私一人に任せて頂いた中で、スケジュール内で完了したこと。 - Terraform Moduleを作成することにより多くのチームから利用していただけたこと。

# AWS Organizationsを利用したアカウントの管理・運用業務 複数のAWSアカウントを管理するためにAWS Organizations機能を利用した運用業務に携わってきました。 私が主に以下の二つの業務を担当しておりました。 ## 担当業務 - AWS SSOやAWS SCPを利用したUserの権限管理 Userの種類ごとに適切な権限を付与するために、タグの指定があれば編集できる権限を付与するためのIAM Policyを作成するなどといった条件付きの権限付与の設定なども実施して参りました。この業務を通じて、IAMの基本的な使い方から少し応用的な権限付与のための使い方などについても経験することできました。 - CloudFormation StackSetsを利用した構築業務 アカウントごとで共通して構築するリソースをデプロイするために利用しておりました。Cloudformationテンプレート作成についても担当しておりました。 # AWS セキュリティサービスを用いた監視などの運用 会社の方針としてインフラ周りも基本的に開発チームが担当するため、インフラ周りでの設定に関する監視が必要としてSecurityHubやAWS Configのカスタムルールを用いた監視の構築や運用業務に従事しておりました。基本的な監視はAWS SecurityHubで用意されているセキュリティ基準（"AWS基礎セキュリティのベストプラクティス"や"CIS AWS Foundations"）を有効化し監視しており、会社独自の監視としてはAWS Configのカスタムルールを作成し監視しておりました。カスタムルールは、Pythonでの実装も含めて担当しておりました。セキュリティ周りの監視業務を担当させていただき、AWS上で安全なシステム構築するためのセキュリティ面における基本的な知識などについて習得することができました。 ## 担当業務 - SecurityHub及びAWS Configの運用として、ルールに違反した設定の監視 ルールに違反した場合はSlack通知されるように設定し、違反時は設定変更を実施したり設定者に通知したりするなどの運用業務を担当しておりました。 - AWS Configカスタムルールの追加 社内独自のルールの構築として、AWS Configのカスタムルール作成業務

Kubernetes運用業務として従事しました。 以下の内容を実施し、既存の運用からの改善に取り組みました。 ## Pod CPU/Memoryの設定実施および、開発者設定するための布教活動 [課題] 1. Pod CPU/Memory kubernetes 上で稼働している各PodでCPU/Memoryが設定されていないものが複数あり、Node Auto Scalingがうまく作動しない問題がありました。 また、HPAを利用するにあたりNodeがAuto Scalingしない可能性がある状態でした。 2. Probeの設定 Probeの設定が正しく設定されていないことにより、想定以上にPodが再起動されてしまったり、Podの再起動を実施した際にエラーが発生する問題が発生した。 [取り組んだ改善] CPU / Memoryが設定されていないPodを洗い出し、各種設定を実施しました。 CPU Limitsについては、以下の記事を参考にLimitsを設定しない方針にしました。 (参考にした記事: https://home.robusta.dev/blog/stop-using-cpu-limits） Probeの設定についても、Podごとに適切に設定するように変更しました。 また、SREチームで設定するのではなく、開発者にも設定項目の重要性などをしっかりと伝えつつ、一緒に作業することで、 開発者自身で継続的に適切なPodの運用ができるように取り組みました。 ## GKEおよびMWのUpgradeの定期実施 [課題] IstioやKubernetesのUpgradeが滞っている状態になっていました。 [取り組んだ改善] 定期的なUpdateを計画し取り組み、手順等を整備して効率的に対応できるように取り組みました。 手順などは、主にはドキュメントに記載の通りではあるが、チームとして定期的に必ず取り組むように話し合い進めました。 ## 全体を通して意識したこと KubernetesのManifestについては主に開発者により運用する方針であったため、Menifestの書き方や必要な設定については、なぜ必要かを含めて説明しつつ、開発者自身で正しい設定ができるように知識を共有して進めました。 実施した内容は、基本的なことではありますが、SREチームだけが意識して運用するのではなく、開発チーム含めた組織として継続的に適切な運用ができるように、開発者とのコミュニケーションを密に取りながら進めました。 SREチームだけで運用を進めるには限界があるため、KubernetesのManifestの運用などできるだけ開発者が意識してほしいことについては単純に設定するだけではなく、開発チーム自身だけでも運用できるチーム体制になることを意識して取り組みました。

# プロジェクト概要 AWS環境にあるシステムをコンテナ化しGKEに移行するためのプロジェクトに設計から構築までメインの担当として、取り組みました。 コアとなるEC2上のアプリケーションとDBのサーバーがあり、コンテナを利用した運用への移行を進めました。 プロジェクト開始当初は、以下のような構成となっておりました。 - EC2上にコアとなるアプリケーションおよびDB（共有DB）がEC2上で稼働していた - フロントエンドのアプリケーションと一部のAPIがECS上で稼働していた - 比較的新しく構築された一部のAPIはGKE上で稼働していた # 取り組んだ課題と改善に取り組んだ内容 ## 1. EC2およびECSで稼働しているアプリケーションや古いGKE上にあるアプリケーションを新しいGKEへ移行 [課題] - チームメンバーの学習コストが高い状況 当初のインフラ構成として、コアとなるアプリケーションはEC2上で動きつつも、一部のマイクロサービスはECSやGKEで稼働しており、構成として複雑な構成となっておりました。 また、既存で稼働しているGKEに関しても歴史的経緯により、組織としてメインで利用しているGCPのVPCとは別のVPCで稼働しておりました。 構成が複雑になっていることで運用するにあたりどの部分でどこと依存しているのかが分かりにくい状態でした。 [取り組んだ内容] 配属された組織では複数のプロダクトを運用していたのですが、全体の割合としてGCPのGKEを利用して運用してるシステムが多く存在している中で、このプロジェクトで改善したシステムに関してはAWS EC2をメインで利用している状況でした。 以下の点を考慮した結果、EC2およびECS（一部）、古いGKEを新しく構築したGKE（こちらのGKEは組織でメインで利用しているGCPのVPCを共有する形で構築）に移行しました。 - 学習コストを抑えるため 組織としてマイクロサービスを運用する方針かつ、組織全体としてGKEで運用する割合が多いことを考慮すると、組織内でのチーム移動があった場合などの学習コストを低減するためにも、GKEに移行することが妥当だと考え改善を進めました。 - 運用の簡単さ マネージドサービスであるGKEを利用することで運用負荷をできるだけで削減できると考えました。 Upgradeなどの定期的な運用がほぼマネージドで完結するなどの利点があると考えました。また、すでに他のシステムでの運用実績もあり手順などが確立されていたのもGKEへの移行を決めた要因となっております。 - 別システムとの連携が簡単になる 今後の開発を考慮すると会社で運用している別システムとの連携が増えることが予想されたため、そこの連携を簡単にできるようにしていきたいと考えました。 そのため、移行先を既存のGKEではなく、メインで利用しているVPC内に新たに構築することによりネットワーク構成を統一化させるように進めました。 移行するにあたり全てのアプリケーションを一気に移行するのではなく、必要性に応じて移行対象を決定しました。 詳細は以下となります。 - EC2で稼働しているコアとなるアプリケーションをGKEに移行 比較的に新規機能開発において修正箇所が多いアプリケーションになることと、DBへのクエリが多いアプリケーションになるためレイテンシーを考慮し移行対象とした。 - ECSで稼働しているフロントエンドアプリケーションをGKEに移行 比較的に新規機能開発において修正箇所が多いアプリケーションになるため、移行対象とした。 - 別OrganizationにあるGKEの移行 こちらも同様に新規機能開発において修正箇所が多いアプリケーションになるため、移行対象とした。 - そのほかのECSで稼働しているアプリケーションは移行しないこととした プロジェクト当初時点で、機能追加があまりないためこのプロジェクトでの移行では対象外とした。 このプロジェクトでは、GKEの構築や周辺MWの構築も合わせて取り組みました。 具体的には、GKE構築に伴うネットワーク周りの設定、Istio、各種IAM整備などを実施しました。 ## 2. DBがシングルで稼働しており耐障害性が低い状態だった。 [課題] DB (PostgreSQL) がEC2上で稼働しており、1台構成の状態でした。障害が発生した場合にフェイルオーバーできず、ダウンタイムが発生してしまう状況となっており、私がアサインされた際にその問題を発見したため、課題を共有し改善を進めました。 [取り組んだ内容] GCP GKEへの移行を考慮すると、GCPのCloudSQLで運用するのが適切と判断し、移行を進めました。 冗長化構成にすることで、耐障害性を向上させることができました。 また、移行と合わせてQuery Insightsを有効化しクエリのパフォーマンス監視の強化も進めました。 ## 3. 監視が不十分 [課題] EC2, ECS, GKEと複数のインフラ基盤で稼働しつつも、トレースなどの監視が入っていない状態で、障害時にボトルネックになってる箇所の特定の時間がかかる状況でした。 [取り組んだ内容] この課題に対応するために、監視強化としてDatadog APMの導入を進めました。 移行対象となるアプリケーションには基本的にAPMを導入する形で進めることにより、結果的に調査時間を短縮して運用することができました。 ## 4. デプロイが複雑 [課題] EC2やECS,GKEごとにデプロイ手順が異なることにより、運用コストが高くなっている状況でした。 GKEのデプロイについてはパイプラインが整備されておらず、手動によるコマンド実行でのデプロイとなっており、デプロイの安全性にも問題がある状態でした。 [取り組んだ内容] 別プロダクトですでにArgoCDを利用したデプロイを実施していたため、このプロジェクトでも同様にArgoCDによるデプロイの仕組みを導入しました。 # 全体を通して、移行に際して考慮した点 アプリケーションとDBの移行を踏まえてると大規模な作業となるが、移行後のトラブルが起きたときに問題箇所がわかりやすくなるように、段階的にできる限り慎重に段階的に移行することを考え取り組みました。 また、移行対象のDBが複数のアプリケーションから接続される状態となっており、移行前には同じDB Userを複数のアプリケーションで使い回す設定になっていたが、こちらも問題時の調査を簡単にするためアプリケーションごとにUserを作成し利用するようにすることでできる限り、トラブル時の調査を簡単にしました。 移行においては、移行によるトラブルが起きないように慎重に進めつつも、もしトラブルが起きた際も障害時間が短くなるに対策し進めました。 結果として、コアアプリケーション移行時に一部問題になったものの、問題箇所を特定し迅速に対応することができました。 チームとしてk8sのmanifest管理については開発者が担当する方針となっていたため、移行する際にk8s manifestの書き方や適切な設定方法などはSREとして知識を共有しながら一緒に行うように進めました。 具体的には、コンテナのCPU/Memoryのプロビジョニングや設定方法、Livenessprobe/Readinessprobe/Startupprobeの設定、Repricasの数の設定などをなぜ設定するのかや設定方法などを共有しながら移行しました。 また、今回のプロジェクトについては、私がアサインされてから最初に取り組んだものになるのですが、課題の発見から設計改善まで主導して進めることができました。

円安の影響によりコストが増加している問題に対して、GCP GCEインスタンスの費用削減を実施しコスト削減を実現しました。GKE上で Spot インスタンスを利用することでコストを削減しつつ、いつ落ちても自動で復旧できるシステム構築を実施しました。 以下の点を考慮しながら実施しました。 - PodのtopologySpreadConstraints 機能を利用し、Replicaの半分は Spot のNode、もう半分はオンデマンドのNode（安定的なNode）で起動するように調整しました。これにより仮にSpot Nodeが全て落ちたとしても最低限半分のPodは稼働できるようにしました。 - 仮にNodeが停止した状態で処理中のリクエストがエラーになってもリトライができるようにistioの設定でリトライ処理を追加しました。 - Nodeの停止が頻繁に発生する可能性が高いため、PodがGraceful Shutdownできることを確認し、かつ Probeの設定によりPod 起動中によるエラーが発生しないように各種設定を調整しました。 安定的に動いているかどうかの評価としてSLOを活用しました。Spotインスタンス 導入によりサービスの質が落ちていないかどうかのチェックとして、導入後SLOを定期的にチェックし安定的に動いていることを確認しました。 - Nodeが停止した後に、Node上のPodの偏り（特定のNodeに同じPodが起動しているなど）が発生した場合、一定期間後に再配置できるように実施しました。 ★担当業務 ・Spotを導入した場合にも安定的に稼働できる仕組みの設計 ・PodおよびNodeの設定変更および検証 ・Nodeが停止したことを想定した試験の実施 ・各種関係者への構成変更とSpotによる影響の説明