ID:65329さん

概要

ソフトウェア開発プラットフォームの基盤をGitLabからGitHubへ移管するプロジェクトを計画し、現在推進中

規模

SRE 8名

担当業務

現在のSRE業務の中で特に運用負荷となっている、セルフホスティングのGitLabの運用を変えるべく、GitHubへの移管計画を立案。
全プロダクトの開発ロードマップを把握し、移管の進行計画を立て、GitHub Enterpriseの予算見積、各所調整や連携、協力体制の為の事前調整を実施。

約半年の調整期間を経て、会社全体で合意が取れ、現在移管推進中。

各種監査への対応をふまえたOrganizationやTeam、CI/CD等の設計・構築・教育、また運用規程や手順書の準備等を行っている。

目的

社内利用システムに関して、誰が何のリソースをどれだけの種類AWS上で構築・運用されているのかを可視化したい

技術選定

入社当時、本システムの構築に関わったAWS環境に詳しいエンジニアが退職しており、詳しい情報を得られませんでした。そのため、私自身のTerraformの経験を元に一から環境構築に取り組みました。

リソース調査

複数アカウントにて利用されているリソースを一から調査し、リソース全てをリスト化・作業タスク化しました。

• アカウント数：2アカウント
• リソース数：約2,500リソース

Terraform及びGitHub Actionsの整備

TerraformでのIaC化に必要不可欠なGitHub ActionsでのCI/CD構築も一から行いました。

• 既存リソースを管理するTerraformの構成検討
• GitHub ActionsによるCI/CDの構築
• ローカル環境でTerraformのplanを実行できるようにMakefileの用意

チームへの教育

Terraformの経験があるメンバーがチームに居なかった為、整備・構築したTerraformの環境を利用して教育を行いました。
具体的には以下のように進めました。

• Terraform環境の詳細説明
• Terraformのコードの書き方レクチャー
• 既存AWSリソースのimportレクチャー
• レビュー方法レクチャー

結果

• 未管理だったAWSリソース全てをTerraform管理下にし、リソースを可視化することができました。
• チーム全員が初心者状態からTerraformを習得する事で、AWS関係作業の属人化を防ぎ、作業の効率化を行えました。

その他

この内容に関して、アドベントカレンダーに記事を掲載しました。
https://hikarun-sre.hatenablog.jp/entry/2022/12/08

概要

ECS on EC2で稼働するサービスを、セキュリティ等の運用改善の為にECS on Fargateに移管しました。

規模

SRE 4名

担当業務

Go言語で書かれたバックエンドのコードを解読し、ECSで起動する形にアップデートし、サービスインフラを徐々にECS on Fargateに刷新していきました。
サービスをEC2で運用していると必ずセキュリティの問題が出てきてしまい、決済基盤の運用ではかなり負荷のかかる業務となっていました。
手のかかるEC2運用をやめFargateに移行することで、SREの業務負荷軽減を進めました。

結果

これまで4人で運用が大変となっていたEC2セキュリティ対応への工数がゼロになり、片手間になっていた監視改善や可観測性の向上に注力出来るようになりました。

その他

本件は会社のテックブログにて公開した記事がございます。
https://blog.kyash.co/entry/2021/12/12/100000

概要

インフラの部署が独立し、インフラ領域未経験のチームメンバー2名への教育やチームビルディングを行い、メンバーそれぞれが自走できる状態を作り出すことができました。

規模

インフラエンジニア 3名

担当業務

チームの立ち上げに際し、開発メンバーとの業務すり合わせを行いながら、インフラチームの分担ポイントの調整を行ったりしました。
自社サービスの開発運用の業務を進めながら、インフラ構成の設計レクチャー、外部ベンダーとの打ち合わせなど、能動的に業務参加するチームマネジメントを行いました。

結果

徐々に信頼を積み重ね、最終的にインフラチームで行えることや依頼が増え、以下の幅広い業務をこなせるようになりました。
・AWS、GCPでのインフラ構築・運用・監視
・オンプレ、仮想基盤(VM)のインフラ基盤構築・運用・監視
・Cisco製品での社内ネットワーク構築・運用・監視
・社外利用サービスのアカウント管理・社員PCキッティング
・情報セキュリティポリシー指針等の規定類策定

概要

サテライトオフィスの2拠点増加に伴い、オフィスネットワークの設計から現地施行、運用までを一挙に担当しました。

規模

ネットワークエンジニア 1名

担当業務

本社ネットワークと接続するよう、各地方のネットワーク機器を設定し、敷設の準備を行いながら、プロバイダと連携し回線引き込みの契約や工事の打ち合わせを進めました。
実際に各サテライトオフィスに向かい、数泊しながら工事の立ち会いやネットワークの構築を行い、作業を完遂しました。

結果

本社とサテライトオフィス間の接続も快適に行え、実際に社員からも快適さを感想で頂けておりました。
特に営業の部署では、勤務時間内はサテライトオフィスと常にWeb会議を接続して業務おりましたが、特に大きな問題もなく快適という言葉を頂けておりました。

概要

決済に利用するクーポンの発行の負荷に耐えられる上限値を測定するため、本番同等環境を用意し計画実行しました。

規模

SREエンジニア 1名
バックエンドエンジニア 1名

担当業務

負荷検証のシナリオを検討し、現行のユーザー数の伸び率からクーポン発行数の倍率を決定。検証環境でクーポンの発行を行っている際に、AWS ElasticBeanstalkのインスタンスパラメータとMongoDBの負荷を計測。

結果

どのプロセスの負荷が高くなりやすいか、システムの改善点を発見することで、当時のユーザー数の7000倍程度のクーポン発行に耐えられるシステムになりました。

概要

ラジオ風ユーザー生成コンテンツアプリのインフラ構築を担当しました。

規模

インフラエンジニア 1名
バックエンドエンジニア 1名
モバイルエンジニア 2名
ビジネスサイドなど 6名

担当業務

MVP開発からスタートし、ゼロからインフラの構築を1人で担当しました。
開発メンバーやビジネスサイドと連携を取りながら、AWSにてインフラの設計・構築・監視設定等を1人で完遂し、無事リリースを迎える事ができました。

概要

運用コストの改善のため、新しいデータセンターへオンプレ機器の移設を含む引越し作業を行いました。

規模

インフラエンジニア 8名
フロントエンドエンジニア 7名
バックエンドエンジニア 8名

担当業務

インフラエンジニアとして、データセンター引越しに必要な工程を対応しました。
移行計画に始まり、当日VMWareで稼働するサービスをメンテナンスにするためのApacheやDNSの設定投入から、データセンターに設置されている機器全てをトラックで移設、全サービスの復旧作業まで行いました。
およそ60時間に及ぶメンテナンスとなりましたが、無事完遂しました。

概要

運営していたファンサイトの事業売却に伴い、他社のインフラ環境に移管したプロジェクトとなります。

規模

インフラ担当 7名
フロントエンド担当 2名
バックエンド担当 2名

担当業務

インフラエンジニアとして、移行環境の準備を行いました。
移管先となる他社のAWS環境とVPC間接続を行い、Aurora MySQLでVPCを跨いでレプリケーションを組むことで、移行メンテナンスの時間を削減することができました。
入念な作業計画を練り、当日は先方のエンジニアの皆様と円滑にコミュニケーションを取り、無事メンテナンスを完遂することができました。