この度は、4/9(土)~4/11(日)に開催された PHPerKaigi 2022 に4名のメンバーが登壇しました。 今回は、登壇者 4 名からコメントと、他のセッションの感想などをお届けします！
PHPerKaigi 2022 とは
2022/04/09(土) ~ 2022/04/11(月) の 3 日間にわたって PHPerKaigi 2022 が開催されました。今年はオンラインとオフラインのハイブリット開催になります。 BASE はこれまでにも開催されている PHPerKaigi への登壇並びにスポンサードをコミュニティ貢献活動として行って参りました。
登壇者のコメント
川島 (@nazonohito51)
TechLeadの川島（@nazonohito51）です。
今回はBASEがサービスとしても組織としても成長していく中で生産性を維持するためのアーキテクチャ戦略についての発表をさせていただきました。社内でこの戦略が打ち出されたのはかれこれ2年ほど前になるのですが、明確な形で社外に公表されたのは今回が初になります。
この戦略はアーキテクチャの本からチーム・組織・文化などの本から「学習する組織」といったテクノロジー系とは言えない本まであちこち読んだ末に考え出されました。実態としてはクリーンアーキテクチャやマイクロサービスなどのアーキテクチャパターンというより、進化的アーキテクチャ＋DevOpsといった趣旨の内容であると言ったほうが近いと思います。中長期的な期間で考えればアーキテクチャに固定的な解は存在せず、システムを取り巻く環境の変化の中で常にバランスを取り続ける変化する動体である必要があります。そして変化の方向は、その時の目先の問題だけを反応的に局所最適で解決するのではなく、常に何かしらの目的を達成するような構造へ向かうような指向性が求められます。そして弊社における目的とは資料の前半で触れられていたようなものでした。
各所の反応を見る限り「モジュラモノリス」という単語に惹かれた方が多そうな印象ですが、趣旨としては中長期的にアーキテクチャに対してどんな姿勢で行くかの考えを整理したものがメインコンテンツになります。モジュラモノリスはその中の中心ではありますが一部に過ぎず、「モジュラモノリス」という単語そのものに「組織の生産性」という期待を寄せているならば何か見落としがあると思います。この資料で終始徹底したのは技術的な方法論からは入らない、という点で、事業と技術の整合性をどう取るのかについて一番エネルギーが使われています。
このアーキテクチャ戦略は未だに手探りの部分がほとんどの状況ですが、これから社内で少しずつ進めていく予定です。
Discordチャンネルに送られた質問について
Discordに送られてきた質問はおそらく他の多くの方も持たれる疑問だと思われるのでこちらにも記述します。
モジュラモノリスの時点ではDB分割をしていない状態なのか？
そうなります。理由はDB分割の境界はドメインが根拠であるべき、と考えているためです。ドメイン基準で分割したいけど境界線が分からない->DB設計の手戻りはコストが高い->アプリケーションの手戻りはDBよりも低コストなのでまずはアプリケーション（＝モジュール）境界を安定させてからそれをDB設計に反映する、という戦略を立てているため、モジュラモノリス開始時点ではあえてDB分割していません。
漸進的にマイクロサービスへ向かっていくかどうかでモジュールをまたいだトランザクション境界について考え方が変わらないか？
マイクロサービス化するならモジュールをまたいだトランザクションを許してはならないし（マイクロサービス化する時点でトランザクション分かれる）、マイクロサービス化しないならそういうトランザクションを許可する、という考え方にならないか、という質問でした。
結論としてはご指摘のとおりになります。マイクロサービス化する場合、CAP定理にもある通りCAPのいずれかが大きく損なわれます。スライド資料中にも赤文字で記述していますが、モノリスと分散システムにおけるデータ整合性に対する戦略は根本的に異なります。モジュラモノリス時点でやれていたことはマイクロサービス化しても全てが同じようにできるわけでは決してありません。トランザクション境界に対する明確な戦略は打ち出せてはいないのですが、少なくともモジュラモノリス時点で同一トランザクションで処理することもできれば別トランザクションに分けることもできるという選択肢を用意しています。もちろんイベントドリブンな結果整合性の処理を実現することはモジュラモノリスにおいても出来ます。モジュール境界線が明確ならはじめからトランザクションを分けたり、結果整合性の処理にしてしまうことが後のマイクロサービス化するときに有利になります。が、境界線が明確でないなら無意味に更新処理が複雑化したり、更新が反映されていない参照が発生する可能性をもたらしてしまったり、あるいは「モジュール境界線自体が後から見直しやすい」というモジュラモノリスのメリットを一部手放すことになる可能性もあります。トランザクション境界に対しては現状画一的な判断はできず、都度判断することになることになると考えています。
あと実は、発表中には触れませんが、BASEで実際にマイクロサービス化する箇所は極めて限定的になるのではないかと考えている背景もあります。少なくとも全モジュールがマイクロサービスになって動いているような未来はほとんどありえないだろうと考えています。
モジュラモノリスというパターンについて
モジュラモノリスというパターン自体は「こう作れ」という明確な指示があるわけではないので、自社が「モジュール」という構造を通して何を実現したいかによってその姿は変わってくると思います。弊社はクリーンアーキテクチャをベースにしましたが、これは一例に過ぎません。「マイクロサービスアーキテクチャによって何を達成したいのか明確に把握していない場合には、マイクロサービスアーキテクチャは悪いアイディアである」という言葉はモジュラモノリスにおいてもそのまま当てはまるかと思います。
スライド資料だけを見て動画を見てない方には誤解を生みかねないのでこちらの記事でも触れさせていただきますが、モジュラモノリスは決して銀の弾丸ではありません。マイクロサービスとは別の形をした諸刃の剣です。振り方を誤ればきちんと怪我をしますのでご注意を。
永野 (@glassmonekey)
BASE BANKチームでEngineering Program Managerをしている永野(@glassmonekey)です。
今回は個人開発や副業で扱ってるGraphQLに関して、普段業務で扱ってるPHPを通してどうなのかをトークしました。今回事前収録が個人的にも初めてで運営の皆様にはご迷惑をおかけしました。
弊社ではGraphQLに取り組んでいるわけではなかったのですが、改めて導入すべきかどうかを漠然と考えていたので、発表資料を作る過程を通して良い思考実験になりました。皆様も迷ったら登壇駆動はおすすめです。
発表後には、GraphQLの導入に迷ってたがかなり参考になったといった感想をいただく機会もありかなりの励みになりました。特にオフラインだったので直接感想を言い合えるという体験は最高でした。
これも運営の皆様の調整あってこそだったと思うので、改めてありがとうございました。
大津 (@cocoeyes02)
Product Dev Division / Service Dev Section に所属している02（@cocoeyes02）こと大津です。 今回はコミットメッセージ軽量規約「Conventional Commits」の説明と関連ツールを使ってみた様子をトークしました。
PHP カンファレンス沖縄 2021でトークした リーダブルコミットのすゝめ でも少しだけ「Conventional Commits」について触れましたが、今回はガッツリ環境を用意して試すところまでやった他、「Conventional Commits」の公式ドキュメントサイトにIssueやPRを出すところまでやってみました （とはいえ反応薄くてちょっと悲しい・・・）
今回使用した ramsey/conventional-commits ですが、導入の提案 Issue を laravel/framework や CakePHP など PHP フレームワークのリポジトリで出してみようかなと思っています！ 導入そのものよりも、PHP OSS コミュニティ界隈の人がコミットメッセージについてどう思うか議論するというのが目的です。 分かりやすいコミットメッセージのメリットをもっと多くの人が享受できるよう、今回の発表以外でも動いていきたいと思います！
炭田 (@tanden)
Product Dev Division / Service Dev Section に所属しているtanden（@tanden）です。 今回のLTでは「Webサービスのバウンスメール処理の事始め」ということで、そもそもバウンスメールとは何なのか、AWS SESをつかってバウンスメールをサービスにどのようにフィードバックするのかを簡単に発表させていただきました。
LTの発表は事前収録ではなかったので、ココネリホールの会場での発表でしたが、オンラインでの気軽さや視聴のしやすさはもちろんあるのですが、オフラインでの発表の雰囲気はやはりいいな、素敵だなと改めて思いました（その分緊張もすごいのですが）。 素敵な雰囲気の会場を作ってくださった、運営の皆さまに改めて感謝申し上げます。ありがとうございました。 個人的な心残りは、LTで笑いを全くとらない真面目な発表になってしまったことです。次回はもっとフランクなLTに挑戦してみたいと思います！（笑）
他のセッションについて
若菜 ( @wakanaction )
Product Dev Division / Service Dev Section に所属しているwkです。
Day1とDay2の少しだけ、オンラインで視聴参加しました。 いくつかかいつまんで感想書きます 👨🍳
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント @t_wadaさん
- ついにt_wadaさんのセッションをリアルタイムで聞くことができ、感激...！
- PHPerのみならず、そして初学者から上級者まで広い範囲の方に刺さりそうな内容だった
- 中でも、以下を用いて堅牢な設計を考えていく運びが大変ためになった
- 型宣言
- 列挙型
- モデリング
- 普遍性と等価性
- 完全性
- 責務の配置
- メソッドに渡る値を型宣言によって絞る、さらに扱う内容が限られている値は列挙型で絞る、といった具合
- 度々、プログラマが知るべき97のことから引用されていたが、中でも以下を重点に置いていた。自分の業務でもぜひ参考にしたい考え方だった。
いいインターフェースの条件とは、正しく使用する方が 操作ミスをするより簡単 誤った使い方をすることが困難
「不安や疑念はテストに書いておく」
- 業務ロジックに限らず、FWの挙動、組み込み処理の動きなどもテストに残しておくことで、PHPの思わぬ落とし穴に気付けたり、一方を直したら一方が壊れた、なんてことに気づきやすくなっていて、精神衛生としてもすごく良かった。
総論：設計やコードレビューの際に常に念頭に置いておきたいような、即業務に活かしていける内容だった。型厳格な方向に進んでくれたPHPの恩恵に感謝しながら頑張ります
コミットメッセージ規約「Conventional Commits」を導入してみよう！ @02 さん
- Commitメッセージ、わかりやすく書きたい気持ちはあるものの、実際どうしたら良いかいまいちわかっていなかった
- 日本語で丁寧に書いてみたり、英語で統一して書いてみたり色々試した
- Commitメッセージに関する規約があるのは初めて知った
- フォーマットが決まっており、「Prefix (feat, fix, など) 、タイトル、本文、フッター、破壊的変更」のような内容でcommit メッセージを書く
- 多少規約が厳しめに感じたが、それくらいの方が規約を用いる意味があるか。または続けやすい形で一部取り入れるのも良いのかも。
- また、コミットメッセージをわかりやすく書いていきたいと考えた時、副次的に以下のような考えにも至った。
コミットメッセージをわかりやすくしたい ↓ コミットに含む内容をわかりやすくしないと、わかりやすいメッセージは作れない ↓ 適切な範囲でコミットを切る意識が育てられる！
総論：大規模開発において、Commitメッセージが残す情報は重要であるため、試しにでも実施してみようと思った。 普段使っているSourceTreeでは複数行にわたるCommitメッセージが書きやすいため、試しやすいと思った。
shiiyan（@shiiyannn）
Product Dev Division / Service Dev Section に所属しているshiiyanです。
PHPerKaigi2022のDay1とDay2をオンラインで参加させていただきました。 印象に残ったいくつかの発表に感想を書きます。
day1 - MongoDB に溜まった約1.6億レコード、データ量1TBのあらゆるサイトの記事データを BigQuery で高速検索できるようにした話 植江田さん
大規模データ処理関して、最近業務上でも課題がありました。こちらの発表は課題解決のヒントになれるかと思い、PHPerKaigiの中に特に興味を持ちました。
MongoDBに保存されたデータについて以下のことが紹介されました。
- 様々なサイトから記事をクロールしクリップする
- クロールした記事データをMongoDBで保存
- 1日で10万件のレコードが保存される
1日10万レコードならば、1ヶ月で300万レコードとなり、数年経てば約1.6億ととんでもない規模になっていくことがわかりました。
データ移転中の課題について以下のことが紹介されました。
- 動的スキーマから静的スキーマへの移行課題
- 存在しないカラムがあるとエラーとなる
- カラムの順番が変わるとエラーになる
- 処理時間とサーバーストレージ容量の課題
- 移行処理が完了までに20時間以上が必要
- 移移行処理が完了までに6000以上のcsvファイルが必要
課題に対しての解決法について以下のことが紹介されました。
- 存在しないカラムにnullを入れる
- PHPの連想配列でカラムの順番を固定した
- ストリームコピー（
stream_copy_to_stream）を利用すれば2倍高速した
動的スキーマを採用したデータストアでは、カラムが利用中で増えても、カラムの順番が変わってもエラーなく使い続けます。マイグレーションが不要でスキーマの変更やメンテナンスがしやすい一方で、静的スキーマのデータストアに移行する時に、スキーマの整備という手順が発生するという知見を得られました。
また、ファイルを開いて一行ずつコピーする以外に、ストリームコピーというやり方を今回で新しく学びました。高速化というメリットがあるので、今後PHPでファイルに書き出す処理を実装する時に活用できると思いました。
day2 - コミットメッセージ規約「Conventional Commits」を導入してみよう！02さん
今まではコミットメッセージを割と雑で書いていました。そのせいで、PRのコンフリクト対応時やgit rebase時に苦労した経験がありました。
『コミットは他人が見るものだから、他人が書き手の意図を理解できないと❌』というのが発表の内容にありました。まさに、その通りだと思いました。コミットはpushするだけのものではなく、将来の自分や他人がその意図を理解できないと意味がないと理解しました。
Conventional Commitsというコミットメッセージの軽量規約も紹介されました。 featやdocsなどのコミットメッセージのプリフィックス前から知っているものの、コミットメッセージ規約を勉強するのは今回が初めてでした。
発表に利用されたサンプルリポジトリのコミット履歴を眺めると、規約に沿って書いたコミットメッセージがあるとソースコードを見なくても、何をやったのかを想像できることが実感できました。
発表の後、choreというプリフィックスはいつ利用されるかを調べました。
chore (updating grunt tasks etc; no production code change)
私の理解では、featやdocsなど明確な目的があるプリフィックス以外、本番コードに影響しないその他的な変更があった時に使います。
また、破壊的変更（Breaking changes）があるときに必ずフッター部分で明言することも覚えました。
今後はぜひ規約に合ったコミットメッセージを書いて、コミットメッセージが役立つようにしたいと決めました。
最後に
今回計 4 名のメンバーが登壇する機会をいただき、 PHP コミュニティの盛り上がりに貢献することができ大変有意義な時間となりました。 また自身の発表以外にも、多くのスピーカーの発表を通して各々が新たな知見や気づきを持って帰れたと考えております。
業務でお忙しいにも関わらず、スタッフの方々には多くの時間をカンファレンス準備へ割いていただいたかと思います。この場を借りて心より御礼申し上げます。
今回はトーク編の記事となっております。他にもスポンサー編、アンカンファレンス編、スタッフ編の記事を投稿する予定です。 それでは、来年もまた皆様にお会いできることを楽しみにしております！
