ドリコムシステム運用の今

2020年9月15日公開

SRE部の大原です。
この記事では、ドリコムのシステム運用についての共有を行いたいと思います。

ドリコムのシステム運用

システム開発における文脈の「運用」という言葉は、様々な意味がありますが、その中でも私の携わっているプラットフォームシステムにおける「運用」は、以下を指します。

プラットフォームの新規機能開発
定期的なシステム診断(負荷試験や脆弱性診断)
キャパシティプランニング(プロモやイベントに合わせたサーバー増減オペレーション)
システム証明書やクラウド等のメンテナンス対応

この記事では主に「プラットフォームの新規機能開発」にフォーカスして私達のシステム「運用」の紹介をしたいと思います。

チーム構成

本稿で取り上げるプラットフォームの開発チームは、スクラムによって開発運用を進めています。
スクラムチームは3つあり、それぞれのチームが担う責務は以下となります。

国内の機能開発/運用
海外の機能開発/運用
インフラ/SRE業務/管理・顧客用機能の開発/運用

次節のシステム/アーキテクチャにもある通り、プラットフォームシステムは複数のリポジトリベースで開発を行なっている為、それぞれのチームが同じリポジトリに対してコミットとリリースを行ないます。（それについてのメリデメは後述します）

システム/アーキテクチャ

プラットフォームのシステムは複数のサブシスから構成され、API（Rails）の共通モデルは、専用のリポジトリで管理しています。また、プラットフォームが提供するミドルウェアやWebフロントエンドはこれらのAPI群を呼び出してサービスや機能を提供します。

図の様に、それぞれのサブシス毎にリポジトリが存在し、それらに対してエンジニアがコミットとバージョニングを行なって、サービスをリリースします。構成が複雑になる事で、バージョニングやリリースハンドリングのオペレーションも複雑になるデメリットがあります。

しかし、メリットとして

単一のデータベースを利用できる（ので、データの管理やDB自体のバージョニング/スキーマ管理が楽になる）
それぞれのサブシスを異なるチームで開発できる（管理画面とデベセンはリリースまでは外注していました）

があげられます。

プラットフォームでは外注でサブシスの一部を開発したという歴史的経緯もあるのですが、プラットフォームのデータは特にセンシティブな性質をもっている為、複数のサブシスが複数のデータベースを持つ構成にしたくなかったという理由もあります。

リリースサイクル

開発チームのスクラムは2週間スプリントの為、リリースもそれに合わせたサイクルになっています。

プラットフォームのリリースは、緊急時をのぞいて基本的に週1回、スプリント中に2回行います。また、リリースの対象は、本番環境と顧客が開発を行うサンドボックス環境の２つです。

当然、staging環境でのQAチェックが通らない限り、sandbox、本番環境に対してリリースは行ないません。また必要に応じてリリースしたい環境に対してQAチェック/エンジニアチェックと、少なくともリリース後1時間はエラーレートやシステムの異常値が無いか、システムモニターで監視します。

リリースオペレーションはそれぞれのサブシス毎に担当者が割り振られ、その人がリリース後監視も担当し、異常値が無いことを報告して、リリースオペレーションが完了します。

リリースのオペレーションコストの削減

ここまで紹介した通り、プラットフォームのシステムは単一アプリではなく、複数のサブシスから構成される為、リリースの管理が煩雑でした。
それを見越して、かなり初期の段階から、リリースオペレーションの負荷を緩和するために、

リリース作業の簡易化
CIへのリリースオペレーションの組み込み

を重視してきました。

リリース作業の簡易化

リリース作業を簡単にする為、リリース環境と開発用のgitブランチを1対1に固定化し、cherry-pickではなくブランチからブランチへのmergeで完了させる戦略をとりました。

ブランチのワークフローは以下です。

それぞれのブランチと環境は以下のペアとなっています。

本番環境 -> masterブランチ
sandbox環境-> sandboxブランチ
QAチェック環境 -> stable-stgブランチ
安定板開発環境 -> stable-devブランチ
開発用環境(dev01〜03) -> エンジニアが好きなブランチをdeployできる

CIへのリリースオペレーションの組み込み

リリースのオペレーションは手動ではなく、基本的には全てCI（circleci）のワークフローに乗せて行なっています。

本番とsandbox環境は「approve」ボタンを押せば自動で対象の環境にdeploy(リリース)されます。ですので、担当者が行う作業はボタンを押すだけです（ただし、事前の自動テストが失敗した場合は、リリースは不可能です）。

まとめ

今回紹介したプラットフォームはサブシスが複数あったり、開発関係者が複数のチーム・会社に渡っている事から、自動化やオペレーションの簡略化を開発初期のフェーズから行なってきました。現在では、本番環境に対して変更を入れるのにかかる時間は30分〜1時間程度となっています。とはいえ、運用オペレーションの効率化や改善はできるポイントがまだまだたくさん残っています。言い換えればもっと運用を効率化でき、開発のサイクルを早くする事が可能という事です。

さらにサービスをドライブする為にも、エンジニアが気持ちよくシステムを開発できる為にも、開発体験(DX)を向上させる為にも、引き続きフロー改善と自動化を駆使して、運用の改善をプラットフォームチームは進めていきます。