今月よりPR TIMESの執行役員CTOになりました。@catatsuy こと金子です。
今回のエントリーはPR TIMES 開発者ブログの記念すべき初投稿ということで、PR TIMES開発本部としてこれから目指していく方向について書いていこうと思います。
3つの成果指標
PR TIMES開発本部はこれから以下の3つに力を入れていきます。
- システム全体のセキュリティ向上
- マイクロサービス化を進めてモノリスの責務を減らす
- モノリスのレガシー改善
それぞれが相互に密接に関係していますが、それぞれ説明していきます。
システム全体のセキュリティ向上
PR TIMESはサービス開始当時から大きなシステム変更をせずにモノリスなPHP製のアプリケーションに対して機能追加を行ってきました。それもあり、セキュリティについて改善したいことがたくさんあります。
「セキュリティを向上する」と言うだけなら簡単ですし、数値化して改善した量を示すことも難しいです。なので数値として「○％改善した」ということは難易度が高いことですし、ここまでやったら完璧みたいなものもありません。そこでまずは私がCTOとして緊急度の高いタスクを整理して優先度順に1つ1つ対応していきます。
またセキュリティ向上は一人ではできません。セキュリティ向上のためには開発本部内の社員全員の技術力の底上げも重要です。そこで主に新卒から入社したメンバーを中心にセキュリティに限らずに研修内容の充実・教育に力を入れていきます。具体的にはまず社内ISUCONの開催を予定しています。他にもプロジェクトの初期段階の方針相談にCTOの私が入ることで仕事の進め方などを伝えていきます。
PR TIMES社は、あらゆる部門がその職能を活かした知見や経験を発信して、同じ職能で働く人たちに貢献できるようになりたいと考えています。開発本部がPR TIMES社を牽引していくために、この開発者ブログなどを通じて社内の取り組みを発信していきます。そうすることで優秀な人を採用しやすくなり、セキュリティの対応も取りやすくなると考えています。
マイクロサービス化を進めてモノリスの責務を減らす
現在のモノリス側のソースコードの変更は容易ではなく、新機能追加に非常に時間がかかっている現状があります。そこでマイクロサービス化により、一部機能を別のWebアプリケーションに切り出すことでモノリスの責務を減らし、サービスの機能追加・改善を行いやすくするプロジェクトがこれまで進行してきました。この現在進行中のマイクロサービス化を「マイクロサービス化第一フェーズ」と命名し、このマイクロサービス化第一フェーズを引き続き進行させていきます。
他社のマイクロサービス化事例ではマイクロサービス化を行うまで新機能追加は止めて、現行のサービスと互換性がある全く同じサービスを作り、少しずつリクエストを移行していくことが一般的だと考えています。しかし現在進行中のPR TIMESのマイクロサービス化第一フェーズはPR TIMESの一部の機能を別のWebサービスとして分離して実装し、機能の要件定義し直しとリニューアルを行います。
勘の良い方ならこの方法は難易度が高いことがわかると思います。理由はリニューアル時の仕様に問題があった場合、システム全体のリリース自体が不可能になるからです。しかしPR TIMESの場合、歴史があるサービスということもあり、機能の明文化された要件はありません。そこでプロダクト本部と密に連携を行い、要件定義し直しと、リニューアル時の仕様に手戻りがないように最大限の努力を行った上で、マイクロサービス化第一フェーズを進めていきます。
このマイクロサービス化第一フェーズではプロダクト本部側で優先度が高い機能のリニューアルを優先します。これによりモノリス側の責務を減らし、かつリリース後の機能改善の速度を上げていきます。
そもそもPR TIMESの開発本部の現在の人数は20名程度であり、マイクロサービスアーキテクチャの最大のメリットである
組織の拡大においても小さな自立独立したチームによる組織を編成し組織としてのパフォーマンスを最大化する
https://deeeet.com/writing/2019/05/20/why-microservices/
の恩恵が受けられません。現在のPR TIMESにおけるマイクロサービス化の目的はモノリス側の責務を減らすことと、その後の改善速度を上げることに焦点があります。
そのため、現在ではプロダクト本部側で優先度が高い機能を別のサービスに分割することに集中していく方針です。今後機能ごとのサービス分割が進んだ場合、「マイクロサービス化第二フェーズ」を定義して方向性を変更する予定ですが、現在ではまずサービスを分割することに集中します。分割内容もアプリケーションコードの分割を最優先しています。データベース分割は必要性がない限り、無理に行わない方針です。
モノリスのレガシー改善
マイクロサービス化を進めていきますが、モノリスがなくなるわけではありません。マイクロサービス化はモノリスを放置して良い理由にはなりません。モノリスのレガシー改善も行っていきます。
しかしモノリスに対するレガシー改善はやっていくと際限がありません。もちろんセキュリティ向上の優先度が高いですが、それ加えて業務効率を改善する観点から優先度の高いタスクを決めて対応を行います。大胆な変更も辞さずに行います。当然それによる障害も起こることが想定されます。そこで各部署とのコミュニケーションを密接に行ったり、確認できる環境を構築することを優先するなど、できる限りの確認と共有を行った上で行っていきます。
PR TIMESのレガシーなアプリケーションはPHPで書かれているWebアプリケーションでしかありません。時間さえかければ必ず改善できます。優先度が高く、できるところから少しずつ進めていきます。
私個人の話ですが、私はこれまで大規模PHPアプリケーションのHTTPS化（前編・後編）や、PHP 5.5からPHP 7.1へのアップデート、そのアップデートのためのミドルウェア変更（Kyoto TycoonからRedis・MySQLへ）など、いくつも大胆な変更を既存システムに対して入れてきました。これまでの経験を活用し、力強く進めていきます。
最後に
今回紹介した成果指標に関する数値化についてはまだ考えられていません。これについてはDX Criteriaを利用することや、デプロイ回数を指標にすることなどを考えていますが、これからの課題としています。
本記事では弊社の内部の状況とこれからの目標を赤裸々に書きましたが、これは私がPR TIMES社の生に近い実情を発信することで、PR TIMESを本当に改善したいと感じる人たちに届いて欲しいと考えているからです。私がPR TIMESに入社してからまだ数週間ですが、私一人でできることの限界を非常に感じています。一緒にPR TIMESをもっとよくしてくれる仲間を求めています。今のところtwitterのDMも開放しているのでお気軽に相談してください。よろしくお願いします。
