この記事は ヤプリAdvent Calendar 2022 初日の記事となります。
ヤプリのSREマネージャー望月です。
最近家でしいたけが栽培できるキットを購入して運用しておりましたが、1ヶ月経過しても全く芽が出ない（通常1週間程度）というインシデントに遭遇しております。
昨年はテックブログ編集長として記事を執筆しましたが、今年はテックブログ改善委員会というプロジェクトが立ち上がり、素晴らしい勢いでテックブログを盛り上げていただいています！
そのため編集長としての役割は一旦お休みとなりまして、今回はSREマネージャーとして2022年の振り返りをしていきます。
ヤプリのサービス規模は年々拡大しており、SRE領域でもスピード感を持って業務を進化させていくことが求められます。
その中で2022年に実施した取り組みの中から3点を紹介させていただきます。
- セキュリティ強化
- 監視アップデート
- コスト最適化
セキュリティ強化
2020年12月の株式上場にも後押しされて、近年SREとしてはセキュリティ強化に多くのリソースを投入しています。
2022年に実施した主な取り組みは以下となり、ここから2点を紹介していきます。
- AWS Control Tower導入
- Session Manager経由のSSH接続
- 社内用サービス管理サイトのOkta連携
- WAFの適用範囲拡大
- OS・ミドルウェアを適宜アップデート
- ISMS取得にかかる対応(取得はITグループ主導)
AWS Control Tower導入
導入の背景としては、AWSアカウントが増加していく中で管理が煩雑になっており、アカウント毎にセキュリティレベルのムラが生じるといった課題が顕在化したためです。
AWSのベストプラクティスに沿った運用を継続的かつ統合的に実現できるといった点で、ヤプリのこれからのニーズにマッチしたソリューションであったと思います。
詳しくは羽渕さんによるYappli Tech Conference 2022の登壇レポートをご参照ください。
エンジニア組織の拡大とともに、細かいところまでSREの目が行き届かないケースも出てきています。
これからもサービス化・自動化を交えながら、限られたSREのリソースを投入すべき箇所を選択・集中させる必要性を強く感じています。
社内用サービス管理サイトのOkta連携
こちらは単純なログインID・パスワード認証をしていた社内用サイトに対して、Okta連携を導入したという案件です。
Okta連携というとパッと思いつくのはSAML等によるSSOかと思いますが、こちらの案件は少し別観点での実装となります。
前提としてこのサイトにはSSOの受け口が用意されていないので、まずサイト側にSSOを実装する必要があります。
現実的なラインではそれが難しかったため、ALBでOIDCを使用したOkta認証を挟むという方式を取りました。
これならサイト側に手を入れることなく実装できるため、低コストで社内的に優先度が高かったセキュリティ強化を実現できた案件となりました。
このような様々な活動を元に、SRE NEXT 2022ではヤプリのセキュリティ強化の歴史について発表させていただきました。
2021年以前の話題も含まれておりますので、ご興味がありましたらアーカイブ・発表記事をご覧ください。
監視アップデート
監視周りではNewRelic導入とそれをベースにした監視基盤のアップデートを実施しています。
ヤプリでは2019年にSREが発足してから、2020年頃までにベースとなる監視の考え方や仕組みが構築されました。
その後は安定してサービス運用ができるようになったことで、あまり大きなアップデートはしていませんでした。
今回NewRelicを導入・移行して、さらに監視の考え方自体もアップデートしており、実施した改善のうち2点を紹介します。
Scripted APIを利用した監視
これまでヤプリではいわゆるPing形式の外形監視が採用されていました。
しかしながら、単純なヘルスチェックは問題ないものの、ユーザーが実際に利用するリクエストでは問題が発生しているといったケースが発生してきていました。
もちろんサービスが増えたり、機能が増えたり、インフラ経路が増えたり様々な背景はありましたが、全てをカバーするような口を用意して、また将来に渡ってメンテナンスしていくことは現実的ではありませんでした。
そこでユーザーが実際に利用している通信をトレースした監視（例えばアプリで「ポイントカードを表示する」「スタンプカードを押印する」など）をScripted APIというNewRelicの機能を利用して実装するという方針にしました。
これによってユーザーが実際に直面しているインシデントに「いち早く」「確実に」気づくことができるようになりました。
実装もNewRelic側に閉じているため、動いているサービスに手を入れる必要もなく安心して今後も拡張していけることが強みです。
障害の予兆に気づくための活動
ある時、直近で発生していたインシデントを振り返っていて、事前に障害の予兆があったケースに気づきました。
特定時点を境にあるメトリクスが緩く継続的に変化していたのです。
しかしながらアラートの閾値に引っかかるレベルではなく、結果的に処理集中時に一気に閾値を超えて障害が発生していました。
こういったケースに事前に気づいて対処できるよう、NewRelicで作成していた全サービスのメトリクスを俯瞰して確認できるダッシュボードを、週次のSRE定例ミーティングで確認することにしました。
直近1週間のスパンでダッシュボードを確認することで、「この日からサービスAのCPU使用率が緩く上がってきているけどリリース起因かな？」「このホストだけネットワーク送信爆増しているけどおかしくない？」といった形で変化に気づいて事前に対処できるようになりました。
こちらを含む様々な監視アップデートについて、Cloud Operator Days Tokyo 2022にてNewRelic様と共同で発表させていただきました。
コスト最適化
2022年は円安を要因としたコスト増への対応に追われた年でもありました。
ヤプリではドルベースで請求される各種サービスを利用しているため、各種コスト削減を実施しても円安の増分が上回ってしまう状況が続きました。
その中でもコツコツと積み上げている対応をいくつか紹介します。
開発環境のインフラ刷新
ヤプリではAWS上にプロダクション環境を簡素化した数十の開発環境が用意されています。
開発したコードをデプロイして動作確認などを行いますが、構築時期によってインフラに差異が結構あったため、それを統一する目的で刷新が行われました。
この過程でロードバランサーを統合したり、不要なリソースを整理・削除したり、コスト削減の取り組みを盛り込むことで、結果的に20%程度のコスト削減に繋がりました。
Terraformを中心としたインフラコード化が積極的に進められている領域だったため、コード修正や環境作り直しの指示だけで人の工数があまりかからなかったことがGoodポイントでした。 IaCの重要さをあらためて確認した案件でもあります。
旧系統のインフラ刷新
ヤプリではSREが組織されるまで、様々なエンジニアが様々なインフラを構築してきています。
昔から稼働しているものの、中身がブラックボックスなインフラもありましたが、今年ほぼ新しいインフラへと移行・統一が完了しています。
単純にインフラコストが下がったという面もありますが、エンジニアのメンテナンスコストが低減したことが一番の成果と考えています。
よく分からないものを理解しようとしたり、変な影響がないか怯えながらメンテナンスしたり、数値に現れづらいコストも長く事業を継続するにあたっては馬鹿にできません。
現在はAuroraのReaderオートスケーリングなども進行しています。
来年にかけてさらにFargate/EC2のスケーリングなども推進しながら、攻めのコスト管理ができるような体制を目指しています。
最後に
このブログを書くにあたって2022年を振り返っていると「この取り組みはブログなどでアウトプットしておけば良かったな」と感じる場面が何度もありました。
これまでテックブログは「社外への情報発信」という感覚が強かったのですが、実は社内で参照・活用されるケースが結構あるということが分かってきました。
チームや自身の記録・振り返りとしてもそうですし、新しくジョインしてくれた仲間へのナレッジ共有など「社内への情報発信」というポイントも意識しながら、2023年はもっとブログを執筆・推進していく所存です。
この後のヤプリ Advent Calendar 2022も楽しみにしています！
