昨年8月 SRE NEXT 2024 にて、「巨大インフラ産業で戦うSRE」という内容で登壇しました。
この登壇から1年4ヶ月経ち、その後 OPENLOGI の SRE はどういう歩みをしてきたか
あの時の「Beyond NEXT」[1] にたどり着けているのか、を振り返りながら
現在地を確認し、これからの課題についても軽く触れたいと思います。
「巨大インフラ産業で戦うSRE」のアップデート
オブザーバビリティ
引き続き Datadog を活用しています。
また、登壇資料後半にある各機能開発チームとの Sync Mtg にて
各機能開発チーム用の Datadog ダッシュボードを作り
パフォーマンス状況を振り返る機会を設けました[2]。
IaC
ここはかなり取り組みが進んでいます。
登壇当時はまだ取り組み始め、というステータスでした。
OPENLOGIの中には、サービス開始当初から稼働しているメインシステムと
比較的最近構築された受注連携を扱うシステムの2つがあるのですが
このうち後者の受注連携システム側の IaC（Terraform化）がもうすぐ完了する見込みです[3]。
次に メインシステム側の IaC 化[4]に取り掛かる予定です。
コード品質強化および可視化
こちらは当時と状況が変わりました。
導入していた Code Climate については、導入コストに対して十分な利用価値を見いだせないことから、利用を終了しました[5]。
代替手段として、PR上でのCode Smell指摘には GitHub Copilot を
カバレッジは PHP拡張ライブラリの pcov を利用し、GitHub Actions にて実行するようにしています。
（なおこの代替手段については、SRE 主導ではなく、機能開発チームで対応を進めています）
登壇資料以外の取り組み
HCP Terraform から tfaction への移行
こちらについては、先日 SRE チームメンバーの k-saiki さんが記事を書いています。
こちらを参照ください。
メール配信基盤の移行
OPENLOGI では、サービスから配信するトランザクションメールの配信基盤に
長らく MailChimp Transactional Email (旧 Mandrill) を利用していました。
これを選定した経緯は、あまりに昔のことで社内資料探しても見つからなかったのですが
過去にはまる1日メンテナンスを実施したことがあったり
障害発生時のサポート品質も満足できるものではなかったため、Amazon SES に移行しました。
ミドルウェアアップデート
先程述べたシステムのうちメインシステム側の方になりますが
こちらのアーキテクチャ構成が、EC2 上でアプリケーションを実行している
いわゆる昔ながらの Web-DB のレガシーな構成であり
かつソフトウェアアーキテクチャとしても（巨大な）モノリスであるため
PHP、Laravel、データベースといったミドルウェアやライブラリのアップデートは
影響範囲がほぼ全機能になるため、なかなか着手できない状況でした。
とはいえ、ミドルウェア・ライブラリのアップデート／モダナイズは
セキュリティ面も含めて重要な取り組みのため、継続的に対応を進めています。
来年の前半くらいには、いったんの区切りが見えるかな、という状況です。
現在の課題
ここまで、SRE NEXT 2024 からのアップデートとそれ以外の取り組みを振り返りました。
ここからは、現在私たちが解決したいと考えている重要課題に触れます。
コンテナ化
2つのシステムのうち、受注連携システムについては ECS 上で稼働するコンテナ化がされているのですが
メインシステム側は先も述べた通り、まだ EC2 上で稼働しています。
そのため、サーバリソースの柔軟な運用が難しく、コスト効率も悪く
また、ミドルウェアバージョンアップの際にも足かせとなっています。
これを ECS 等コンテナ環境化へ移行することを進めていきたいと考えています。
さらなるセキュリティへの対応
OPENLOGI はおかげさまでたくさんの荷主様に支持され、ビジネスを伸ばしてきました。
当初はスモールスタートのECビジネスのお客様が多かったのですが
ここ最近は大手のお客様からの引き合いもいただいています。
その際、いわゆるセキュリティチェックがあるわけですが
ここ最近の世間事情もあいまってか、より高度なセキュリティレベルを求められるお客様が増えてきました。
我々としても、このビジネスをより伸ばしていくため、これらの要求に答えていくことが必要になってきています。
結びと謝辞
ここまで、SRE NEXT 2024 の登壇内容の振り返りと取り組んだ改善、そして現在の課題について述べてきました。
実はSRE NEXT 2024 終了後は、社内体制の事情で SRE の体制を立て直すことに全力を注いでいた時期がありました[6]。
また、プライベートでは 2025年 2月から半年ほど育休をいただいていたこともあり
ここに記載した内容は、SREチームメンバーのたゆまない努力と
一時的に SRE チームを助けていただいたメンバー
SRE チームの状況に理解いただいた各機能開発チームの皆様
技術開発部の執行役員の方々のご協力があって実現したものであります。
この場を借りて深く御礼を申し上げます。
2026年も、SRE チームは OPENLOGI のビジネスを信頼性の面から支えるべく邁進していきます。
-
「Beyond NEXT」は SRE NEXT 2024 のテーマでした ↩︎
-
他社事例だと「パフォーマンス定点観測会」などと呼ばれるもの。はてな社では PWG (Performance working group) と呼ばれていて、当時これを参考にしました。 ↩︎
-
正確には、もともと CloudFormation で IaC 化されているものがあったのですが、運用上取り回しにくい課題が見つかり、Terraform への移行を行いました。 ↩︎
-
一部リソースはTerraform 化を先行して進めている箇所もあります。 ↩︎
-
具体的には、PR 指摘が間違ったものが多いなど。Code Climate の PHP 対応状況に課題がありました。 ↩︎
-
詳しくは昨年のアドベントカレンダーで記事にしています。 ↩︎
Discussion