PHP conference 2023 登壇レポート / 開発者向けブログ・イベント

2023年10月8日（日）に「PHPカンファレンス2023」が大田区産業プラザにて開催され、GMOインターネットグループはスペシャルスポンサーとして協賛・登壇しました！

今回は、スポンサーセッション「ConoHaの課金元データ収集バッチの進化と軌跡」と題して、OpenStackを利用しているConoHaの課金におけるシステムの一部に焦点を当てた講演内容をお届けします。ぜひご覧ください。

イベント告知：https://developers.gmo.jp/35808/

登壇者

瀬戸悠平
GMOインターネットグループ株式会社インフラ運用本部アーキテクト統括チームSREチーム

プロポーザル：https://fortee.jp/phpcon-2023/proposal/196a5410-96d5-470c-a975-1fba619c33e7

ConoHaとOpenStackについて

ConoHaは、GMOインターネットグループが提供するIaaS型クラウドサービスで、2013年7月4日のリリースから今年で10周年となるサービスです。2023年3月1日にはゲームに特化したConoHa for GAMEもリリース。基盤はOpenStackで、時間課金を採用したサービスとなっています。

図 1 GMOインターネットグループが提供するパブリッククラウド「ConoHa」今年10年目を迎えました

この時間課金は複合的で、利用が1カ月に満たない場合は時間課金として、例えばメモリ1GBプランだと1時間1.7円で、1カ月間利用すると、月額料金以上の請求は発生しない、という形になります。VPSや追加SSD（Volume）、ロードバランサー、イメージ保存の容量などが課金対象です。

図 2 ConoHaの課金イメージ。1カ月未満の利用だと時間課金、それ以上だと月額課金になります

基盤として使っているOpenStackは、オープンソースで開発されている、IaaS環境構築のためのソフトウェア群で、ConoHa for GAMEではバージョン「yoga」を採用していると瀬戸は説明します。

ConoHa for GAMEのインフラ構成では、各機能の提供や管理を行うコンポーネントごとに分かれていて、仮想マシンのNova、VMイメージのGlance、仮想ネットワーキングのNeutron、認証と権限管理のKeystoneなどといった具合です。

図 3 ConoHa for GAMEのインフラ構成図。OpenStackは複数のコンポーネントで構成されています

各コンポーネントはさらに分割されていて、相互に通信する仕組みをしています。例えばNovaであれば「Nova-api」「Nova-compute」「Nova-conductor」「Nova-scheduler」に分かれています。

図 4 コンポーネント内には複数の機能があり、相互に通信をする仕組みが備わっています

課金システムを独自実装

こうしたOpenStackですが、ConoHaが提供しているような時間課金に直結するようなコンポーネントが存在しないと瀬戸は言います。そこでまず利用したのが、OpenStackで使われるEvent Typeで、「create.end」や「delete.end」といった作成・削除の完了通知を計測すれば利用時間が計測できると考えたそうです。

バッチシステムv１について

図 6 課金のためにインスタンスの作成完了時と削除完了時の時間を計測して利用時間を算出する

ConoHaのシステム構成ではMongoDBに課金に必要な情報が登録されているため、そのまま課金システムと接続するのが自然ですが、課金システムを別チームが作っているため、バッチシステムとMySQLの課金データ用DBを経由して課金システムに接続する形になりました。

図 7 バッチシステムv1の構成。独自実装の課金システムやバッチシステムと連携します

MongoDB上のデータを定期的にバッチシステムが参照し、課金システム側が参照している課金データ用DBに書き込むという仕組みです。これがバッチシステムのv1として稼働しました。

バッチシステムv1は、ConoHaの稼働にあわせて2013年からスタート。php5.4を利用し、1時間に1回実行してMySQLに書き込む作業を実施。合致するEvent Typeを検索して一致したものを取得して挿入するというシンプルな設計です。一人で開発して運用するという状況だったと言います。

ただ、そうした状況だったため、不整合検知の仕組みはあっても完全ではなく、最終的に人の目で確認が必要なのにダブルチェックができないという状況で、そこで瀬戸が参加してスキルトランスファーが実施されることになりました。

実際に参画してみるといくつか課題があったそうです。まずgit管理されていない点、同じ時間課金システムを採用するConoHaの複数リージョンや別サービスで、似たようなシステムが乱立してしまっている点、そしてコードの可読性も低かったと瀬戸は話します。

git管理されていないことの問題としては、課金システム自体は回収が通常発生しない基本システムではあるものの、バックファイルが乱立してしまう問題がありました。様々な名称のファイルが乱立して、引継ぎをしてもどのファイルが実際に利用されているものか分かりづらかったそうです。

図 9 git管理されていないことによる問題。複数のファイル名が並んで、どれが正式採用されたファイルか分からない場合も多い

これは瀬戸が真っ先にgit管理に変更し、バックアップファイルをすべて削除して整理。1サービスだけで1,118件の無駄なファイルが整理されたそうです。gitはバージョン管理ができるため、自動的にバックアップファイルが不要になりました。

複数のサービスでConoHaと同じOpenStackやCeilometerなどを使ったシステムを構築していたためバッチシステムを流用してしまったことで、同じようなシステムが乱立していたという課題に対しては、v1のバッチシステムでは対処が難しく、v2の開発で解決を目指しました。

3つ目の課題であるコードの可読性の低さについては、例えば基本的に変数を3文字に省略して記載されていたため謎解きに近い状態だったと言います。また、コメントもほとんどないので個人的に読みにくかったそうです。結果としてコードを読もうとしても理解に時間がかかり、問題発生時にも対処が遅れる問題がありました。

図 10 オライリーの『リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック』（Dustin Boswell、Trevor Foucher、角征典訳 2012）にあるとおり、固有の省略形は暗号のようで、後から参加した人間には分かりづらい

そして、git管理以外の課題解決を目指して、バッチシステムv2の開発がスタートしました。バッチシステムv1では、ディレクトリ構成が環境ごとに用意されていました。日本リージョン向け、タイリージョン向けなどといった具合に切り分けられ、そのディレクトリの中には同じ名前のファイルが存在していました。

こうしたディレクトリ構成を改め、configや処理部分を1カ所にまとめ、未導入だったcomposerの導入も行いました。composerによって構成管理がしやすくなったそうです。

バッチシステムv２について

図 11 バッチシステムv1のディレクトリ構成。環境ごとにディレクトリが存在するなど冗長

図 12 バッチシステムv2ではこれを整理。さらにphp-cs-fixerを導入しました

そしてさらに導入したのが「php-cs-fixer」です。これは、コード自動整形を備えたツールで、開発者のコードの癖を除去できると言います。OSSであるため無料で利用できることに加え、整形ルールをgitに保存できるので統一しやすいといったメリットもあったそうです。

この取り組みによって3つの課題すべて解決したバッチシステムv2が実現できました。

ConoHaの最新サービスであるConoHa for GAMEでは、OpenStackのバージョンとして「yoga」を採用しました。ところが、課金のための情報を保管するMongoDBに対してコンポーネントのCeilometerがレコードを登録しなくなってしまいました。

バッチシステムv３について

図 13 MongoDBからデータの取得ができなくなったため、Rabbit MQに接続する形に

そのため、Rabbit MQからバッチシステムが情報を取得する設計に変更。それを実現するためのバッチシステムv3の開発に取りかかりました。今までは1時間に1回の情報取得だったのを、リアルタイムにRabbitMQからデータ取得する宇ようにしました。これはphp-amqplibを採用して実現したそうです。