これはなに
この記事はSchoo Advent Calendar2024の7日目の記事です！
はじめまして！株式会社Schooでインフラエンジニアをしている櫻沢と申します。
Schooに参画して約2年が経過しました。
この2年間で取り組んできた内容を抜粋してご紹介します。
この記事がインフラエンジニアやSREとして働いている皆さんの参考になれば幸いです！
ミッション
Schooの掲げるミッションは以下の通りです。
世の中から卒業をなくす
インフラエンジニアとしてこのミッションに貢献するため、以下を自分の使命として取り組んできました。
-
サービス信頼性の向上
-
コスト最適化
-
開発者体験の向上
これらは安心して学び続けられる環境を提供するために欠かせない要素だと考えています。
上記のカテゴリに分けてやってきたことを紹介します。
やってきたこと
取り組み内容を「プロダクトチーム編」と「インフラチーム編」に分けて紹介します。
プロダクトチーム編
Schoo参画当初、私は特定のプロダクトチームに所属し、そのチームの課題解決に取り組みました。
別途インフラチームは存在していましたが、そのプロダクトチームではインフラ運用が整備されていない状況だったのでembeddedとして参加しました。
急ぎで改善する必要があったので、このチーム用の個別最適でインフラ改善を実施しました。
| カテゴリ | やったこと | 概要 | 成果 |
|---|---|---|---|
| サービス信頼性 | NewRelic導入 | 最低限の外形監視しかなかったため、NewRelicでダッシュボード・アラート・ログ収集を実装。 NewRelicの選定理由は、フロントエンド監視が試験導入されていたため。 |
★★★ システム状況が可視化され、障害の予防・検知・調査が大きく改善。 |
| サービス信頼性/開発者体験 | CICD整備 | 手動だったDBマイグレーションやタグ付けをGitHubActionsで自動化。 | ★★☆ リリースの品質向上・工数削減を実現。 |
| サービス信頼性 | バックアップ設計 | DisasterRecoveryの目的でデータバックアップを設計・実装。 | ★★☆ 他リージョンでのサービス復旧が可能に（理論上）。 |
| 開発者体験 | ローカル開発環境の改善 | ローカル環境からAWSリソースにアクセスできるように改修実施。 | ★★☆ ローカルから結合試験ができるようになることで、共用環境の混み合いを緩和。 |
| 開発者体験 | マスキングDBの自動構築 | 開発環境での個人情報マスク処理を改善。 日次で最新データをマスキングするワークフローを構築。 |
★★☆ 開発者による障害調査やパフォーマンス検証の効率性向上。 |
| サービス信頼性 | 脆弱性試験の定期実行 | 脆弱性試験の定期実行を可能にするための環境構築。 | ★★☆ 検知された脆弱性を解消することで、セキュリティ向上を達成。 |
インフラチーム編
その後、全社的なインフラ最適化に取り組むべくインフラチームに異動しました。
全プロダクトでEKSを採用しているため、EKS関連の改善タスクが主な取り組みとなりました。
| カテゴリ | やったこと | 目的・概要 | 成果 |
|---|---|---|---|
| サービス信頼性 | EKSバージョンアップ案の比較検討 | バージョンアップの品質向上を目指し、複数の方法を検討。 | ★☆☆ 構成上の課題があり、結果的に従来通りローリングアップデートを選択。 |
| コスト | コスト分析 | (後述) | ★★★ (後述) |
| 開発者体験 | telepresenceの試験導入 | 共用検証環境を効率的に利用できるようにtelepresenceを試験導入。 | ☆☆☆ 一部アプリケーションに試験導入したものの進展がなく断念。ツールの安定性が課題。 |
| 開発者体験 | 負荷試験の実行環境整備 | (後述) | ★★★ (後述) |
| サービス信頼性 | GuardDutyランタイムモニタリングの導入 | IDSとしてAmazon EKS ランタイムモニタリングを導入。 | ★★☆ 疑わしいコンテナの振る舞いを検知可能に。 |
| サービス信頼性/コスト最適化 | Auroraのスケジュールスケーリング導入 | ピークタイムのみリードレプリカを増築し、コストを抑えながら負荷対策。 | ★★☆ コスト増を最小限に抑えつつ、ユーザー増加への対応を実現。 |
| サービス信頼性 | NodeLocalDnsCacheの導入 | 輻輳が原因でEKS上のPodで名前解決失敗が発生していたため導入。 | ★★☆ 名前解決の失敗が解消され、安定性向上。 |
| サービス信頼性 | Datadogの導入 | 全プロダクトのオブザーバビリティ向上のため、Datadogを導入。 | (2024年12月現在) 仕掛かり中。別途記事にしたい。 |
詳細: 成果が大きかった取り組み
効果が高かったもの・他社の参考になりそうなものを抜粋して詳細説明します。
- コスト分析
- 負荷試験の実行環境整備
コスト分析
課題感
場当たり的なコスト削減対応が行われており、効率が悪い状態でした。
やったこと
一番費用がかかっているサービスから削減対応をしていく方針に変更しました。
例えば以下が課金のサービス内訳だとします。
一番利用料の少ないS3からコスト削減対応を実施しても効率悪いですよね？
パイの大きい順にコスト分析・削減対応をしていく方針にしました。
コスト分析の具体的な手順としては以下となります。
- 「AWSアカウント」毎に費用がかかっている「サービス」Top10を抽出
- 「サービス」の中から費用のかかっている「使用タイプ」を抽出
- 「使用タイプ」のコスト削減施策を洗い出し
上記で施策を洗い出し、効果と取り組みやすさで優先度付けしてコスト削減対応に取り組みました。
成果
金額は記載できませんが、2,3ヶ月で大きなコスト削減ができました。
主に以下の対応を実施しています。
- EC2(EKS)
- Spotインスタンスの本番導入
- Podのrequestsを最適化
- 開発系環境の土日停止
- DB系
- サイズ/RI見直し・統合
- 過剰なバックアップルールの変更
- gravitionへの変更
- CloudWatch
- 不要なアプリケーションログの発生抑止
- カスタムメトリクスの削減
- その他
- 不要リソースの削除
この分析〜対応までのサイクルを定期的に実施していく予定です。
負荷試験の実行環境整備
課題感
Schooではk6を負荷試験ツールとして採用しています。
しかし、これには2つの問題がありました。
- 負荷要件の問題
大量の負荷をかけるにはk6実行用EC2を複数台に分散する必要があるが、その提供ができていなかった。
参考 k6ベンチマーク - コストの問題
負荷試験期間中にk6実行用EC2が起動しっぱなしになってしまい、余計なコストがかかっていた。
上記問題の解消のため、k6実行環境の整備を行いました。
やったこと
k6-operatorを採用しました。
k6-operatorはk8s上でk6を分散実行ツールです。
これを導入することで問題の解消を図りました。
以下の流れで負荷試験を実行できるようにk6-operatorを実装しました。
- GithubActionsから負荷試験のキック
- 指定台数分のEC2ノードが起動してk6の実行が行われるので待機
- 完了のSlack通知が来たら、NewRelic(無料アカウント)で結果を確認
成果
当初の問題を解消できました。
- 負荷要件の問題
負荷試験キック時に分散ノード数を指定可能のため、好きなだけ負荷をかけられる。 - コストの問題
k6実行中だけEC2が起動するためコストを抑えられる。
また開発者からも気軽に負荷試験できるようになったと感謝されたため、開発者体験の向上もできたかなと思います。
最後に
ミッション貢献のため、この2年間様々な施策を打ってきました。
ここでは公開していない小さなタスクもたくさんあります。
私がこれらに取り組めたのは周りのサポートがあってこそなのでSchooメンバーに非常に感謝しています。
特に、レビューをしてくれたり代わりに泥臭い作業を担ってくれたインフラチームメンバーや、取り組みに協力してくれたプロダクトチームに感謝です。
Schooにはミッション達成に非常に前向きな姿勢がありますので、これからも更なる改善を行なって貢献していきたいと思います。
Schooでは一緒に働く仲間を募集しています！