2022-09-25 / 2022-09-27 更新

PHP Conference 2022 セッション紹介・感想

17年続くWebサービスを改善する 〜新卒2年目からみるカラーミーショップ〜

初日のメインセッションでGMOペパボより新卒の方2名が登壇、凄い。発表も大変落ち着いておりセッション中にTwitterでのFBを確認するなど慣れた振る舞いを披露されていた、凄い。

前半はアプリケーション、後半はSRE活動と2部構成となっていた。それぞれ紹介したい。

切り取り方を工夫してアプリケーションを漸進的に改善する / @yammerjp

改善を「漸進的に」行ってきた。要はFeature Toggleだがその目的や方法論を紹介されていた。

一度に多くをリリースするよりも影響範囲を局所化しやすい。新卒で入社した後まず驚いたのが何をリリースするにも影響範囲の調査の量が多い点だったという。

初めて業務でソフトウェア開発に触れる方の多くが感じる驚きだと思うが、17年ともなれば桁が違うはず。勝手な想像だが基盤や実装の関係でテストを書きにくい箇所や手動テストが難しい箇所も多いだろうと推測した。この状況であればFeature Toggleの実装は鉄板のやり方だと思う。

実装としては Vue.jsのWeb Componentモードを使ったとのこと。これも鉄板のやり方だ。少し異なる話題だがGoogle Developers Expert (Angular) の @laco2net 氏も Angular.jsからAngularへの移行で同じ戦略を提唱 している。

より具体的な方法論も紹介された。コード例ではif文を使った条件分岐などを挙げられていたが最終的には Unleash を使って管理したとのこと。「デプロイとリリースを切り離す」と表現していたが、巨大なシステムともなるとデプロイも一苦労だろうからこれも極めて有効な方法だ。

何れも同意しかないやり方だっただけに、そのやり方を実現する仕組み自体の導入の紹介が少なかったのは若干残念に感じた。導入してしまえば楽になるのは間違いないが導入それ自体はそうもいかないはずだ。機会があればこの辺りのノウハウを聞いてみたい。

カラーミーショップの改善におけるSRE活動について / @h0mirun_deux

「SRE」と呼ばれる活動を体現したようなセッションだった。

冒頭ひたすら言葉の定義を説明されていた、と言っても決して退屈なものではなく、SREという言葉を全く知らない人であっても理解できるような実例をまじえながら「SRE」「SLI」「SLO」と言った用語の説明をしてくださった。SRE活動においてこの点はとても重要だ。

信頼性の向上、言葉としては簡単だが企業活動においてこれを行うのは意外と難しい。「信頼」といういかにも人の感覚に依存しそうな指標が相手だ。まずは何を指して「信頼」とするか定義しないことには話が始まらない。定義することで初めて観測が可能となり、観測を通じて初めて制御が可能となる。

登壇者は、仕事を通じて得たこととして次の2点を挙げられていた。

  1. SLI/SLOをベースに物事を考える
  2. 何事も手順化する

自分はアプリケーションエンジニアなので「改善」もつい感覚で行ってしまうことが多い。アプリケーション担当なりに仕様やボトルネックは把握しているので「何が改善に相当するのか」は感覚である程度解る。

これ自体は悪いことでないと思うが活動が属人化してしまうのが欠点だ。「SLI/SLOをベースに物事を考える」という視点は見習いたい。「手順化」とは定義に他ならない。このやり方であれば属人化は避けられるはずだ。

こういった考え方で開発とSRE活動を分離するのは確かに有効なのだが、注意すべきなのはお互いの対立だ。開発にとってSREチームが「突然うるさいことを言ってくる連中」になったり、SREチームにとって開発が「言うことを聞かない人たち」になってしまっては本末転倒どころか逆効果だ。

登壇者は「アプリチームとSREとが対立しないことが大切」と明言した上で「エラーバジェット」という指標を導入したり、SLOを超えそうな箇所があった場合は改善案と共にそれを事前に通知したりと、相互に余裕を持ちながら協力しあえる工夫をしていることを紹介してくださった。

仕事をする仲間として当然の配慮と言ってしまえばそれまでだが、定義し制度化し実行に移す取り組みまでをセットとしているところが実にSREらしい。とてもすっきりしたセッションだった。

AWS CDK に魅入られた PHPer がオススメする IaC から入るインフラの話 / @chatii

CDK in TypeScriptや背景となるIaC技術を題材に「インフラ」の基礎を学ぶことのできるセッション。

冒頭「今日のお品書き」で「PHPerがインフラを理解する必要性」と明言されていた通り、アプリケーションエンジニアがざっくり「インフラ」とだけ認識している、具体的にはネットワーク技術やサーバ技術などの概要を学べるセッションだった。

CDKは私も好きなのでそれだけで楽しかったが、全体を通じ「技術の学びかたを学ぶ」に通じる学びのベストプラクティスを意識した構成だった。

アプリケーションエンジニアもインフラを学んで欲しい、これは私も普段感じている。自在に扱えるようになる必要は無いが、触りの部分を知っているだけで実装の幅やスピードに雲泥の差が出る。例えばこんな具合だ。

  • 「インフラ」に設計上の考慮漏れがあったとして、アプリケーション側でそれを試行錯誤しながら迂回するか、問題箇所を特定し別チームに根本解決を依頼するか。
  • 環境依存の不具合やパフォーマンス問題に遭遇したとして、原因の所在が解らないまま調査に時間を費やすか、別の切り口からの解決を選択肢に入れるか。
  • 「要件定義」「SLA」と言った上流の要求事項に対し、どこからどこまでを自分たちの課題としどこから先を課題外とするか。

私も登壇者と同じく、WordやExcelで書かれた「設定資料」の類と戦いながら学んだ世代だが、AnsibleもCloudFormationも「手動で辛かった作業を自動化してくれる便利なツール」という位置づけだった。それをこのセッションでは「基礎を『手軽に』学ぶ・触れる」手段と位置づける。

アプリケーションエンジニアならコードを書く、同じように「コードを書く」ことでインフラに触れてみようと、こういう切り口。なるほど。

この「なるほど」は確かに、アプリケーションエンジニアが「インフラ」を学ぶ入り口になりやすいと思う。後進の育成を常に考えられている実にちゃちいさんらしい発表だった。

リリースして11年経過したPHPアプリケーションにPHPStanを導入した / @task2021

PHPStan自体の説明と共にChatworkではそれをどのような手順で導入したのかも説明された。私も悩んだ(今も悩んでいる)箇所なので実例を含んだ紹介は非常にありがたい。

検知したい問題を明らかにする

まず目的を「未定義参照と型エラーの検知」と定めたとのこと。そもそもの導入の動機が「本番環境でエラーが発生したから」なのであれば妥当な設定だ。

その上で PHPStan Playground を使いどの解析レベルでそれを達成できるか調査。最低でも「level: 5」が必要という結論。

経験上5はそこそこ厳しい目標設定だと思う、PHPの特徴でもある「緩い」書き方はすぐエラー扱いだ。11年物となるとかなり大変だろうと予想したが、最初は約2万件のエラーが検出されたとのこと。

ここで1つの判断が必要になる。まずはそれらを修正するか Baseline で無視してしまうか。Chatworkの場合は「無視する」という選択肢を採ったそうだ。

私の場合ここでつい修正したくなってしまい(そして遅々として進まず)時間がかかりがちなのだが、導入の動機は (何らか新機能を追加した際などに)本番環境で〜 ということだと思うので、特に問題なく動作している既存のコードを無視するのは実に合理的な割り切りだ。まずは目的の明確化、やはり重要。

運用のための環境づくり

CIでの実行や reviewdog によるPRコメントなどで「導入」は済む。しかし大変なのはここからだ。

私がPHPStanを触り始めたのは3年ほど前だ。1人プロジェクトで自分が書いたコードをレベル0から1,2辺りに上げるだけで相当苦労した。自身はレベル5,6辺りも難なく扱えるようになった上で他のメンバーに導入してもらう際も、説明にそこそこ時間かかった記憶がある。

それなりの「ノウハウ」が必要なのだ。それを次のような方法で乗り越えたとのことだった。

  • エディタとの統合をドキュメント化した
  • 相談のためのチャットルームを設けた

lintや静的解析は「なんか怒られたのでググって出てきた方法で迂回」「それすら面倒なのでエラーが常態化」と言った状況になっているプロジェクトをたまに見かける。それらの多くは場当たり的な迂回が災いして導入前よりも悪い状態になっていたりもする。

ツールは、導入したら終わりではなく運用が重要だ。それらの実践とやり方、この辺りを聞けたのが嬉しかった。

そして半年でレベル8まで到達したとのこと。これは本当に凄い。

フラットなPHPからオブジェクト指向で自動テストのあるPHPへ、そしてフレームワークへ / @77web

様々なカンファレンスで「抽象」について解りやすい説明を披露される @77web 氏のセッション、とても楽しみにしていた。

いつも通り「抽象的な」話かと思いきや、今回はBefore-After含むコード例など具体的な内容も多かった。そして相変わらず解りやすい説明、私自身も後進の育成に携わる身として大いに参考にさせていただこうと思った。

「オブジェクト指向」の説明

「生物」「動物」「犬」「人間」と言った例えによる説明。概念の理解には最適だと思うし私も人には class Dog extends Animal / $dog1 = new Dog() と言った具合で説明する。しかし伝わらない時はどうやっても伝わらない。

同じアプローチの説明でも @77web 氏の手にかかると一気に解りやすくなる。「メリーちゃん」は「チワワクラス」、「太郎くん」「花子ちゃん」は「豆柴クラス」、共に「犬クラス」と言った具合だ。実際の業務でも教育役をやることが多いとのことだったので、聞き手に応じて説明のディテールを変える辺りはさすが慣れていると思った。

概念の理解はできても実務への応用にはまだ遠い。メリーちゃんが動物クラスや犬クラスを継承したチワワクラスのインスタンスであることは理解したとして、「バリデーション」「メール送信」と言った機能にそれをどう活用すれば良いのか。

これを聞かれると、答えは出せても説明には詰まる。この辺りの応用例も様々なイラストでとても解りやすく説明されていた。是非とも実際のスライドや動画で見てほしい。

ここまで説明しきった後に浮かぶ疑問は「何故そのようなパターンでプログラムを書く必要があるのか?」だと思う。これも聞かれて答えに詰まったことがある。これに対し「テストの書きやすさ」という形で説明しTDDの説明へ、そしてフレームワークへ、最初から最後までお手本にさせて頂きたい流れのセッションだった。感謝。

OpenAPIで楽に始めるスキーマ駆動開発実践論 / @komtaki

SwaggerやOpenAPIの概要説明やコードファーストとスキーマファーストの違いを踏まえた上で、スキーマファーストな開発を成功させるにはどのようなポイントを押さえれば良いのか網羅的に説明するセッションだった。

このテーマは一家言持っている。昔からサーバとフロント双方を実装することが多かった身としてネットワーク境界を跨ぐデータの信頼性をどう担保するかは長いこと課題として考え続けている。だいぶ前だが 「バリデーション駆動開発」という独自の用語で登壇させて頂いた こともある。

このセッションでは、タイトルにも「スキーマ駆動」と掲げられている通りスキーマファーストを前提に流れを説明していた。OpenAPIに限らずDSLによる仕様管理を何らか採用するのであれば、選べる状況であればスキーマ先行は鉄則だと私も思っている。

仕様と実装の乖離は厳禁という点も同意見だが、そのためのテクニックが幾つも紹介されていたのがありがたかった。

  • OpenAPI.Tools を活用しコードを自動生成する。
  • OpenAPIのアノテーションを最大限活用する。
  • Postmanそのテスト機能 を活用する。アノテーションはここでも使われる。
  • OpenAPIを前提としたテスト戦略を立てる。
    • 4xx系のテストなどは各ツールの標準機能だけでは賄えない。
    • APIテストやE2EテストはDBのモックなど基板上の工夫が必要。
  • これらをフル活用したテストをCIで回す。

極めて実践的な内容のセッションだった。

実践!ユニットテスト入門 / @Panda_Program

PHPUnitによるテスト実装を切り口としたセッションだが、基礎や座学の部分と実践の部分とのバランスが非常によく取れていたと思う。

PHPUnitのマニュアルだけではPHPUnitの使い方は解るが具体的に何を書けば良いかは解らない。@t_wada さんの訳書 テスト駆動開発 なども併読し学ぶべき。前半案内されていたこれら内容はまさに同意だが、このセッション自体が座学と実践との双方をダイジェストで知ることのできる構成となっており、入門者に教材としておすすめしたいセッションだ。

  • テストメソッドは日本語でwhatを書く。
  • 書く時はarrange, act, assertの順で書く。
  • 読む時はassert, arrange, actの順で書く。
  • 観点の解るassertを書く。
    • 観点が異なる場合(たとえまとめられるとしても)assertはそれぞれ書く。
  • 1テストメソッドは1actが原則。
  • テストもDRY原則の適用は重要。
    • ただし最初から闇雲にDRYにしてはいけない。

このようなテクニックが紹介された。テストはほとんど独学だが長いこと書いてきた自分なりのやり方とも感覚的に一致する。それを確認できたことは大きな収穫だ。

また「ユニットテストからはじめよう」をAnswerとしつつ、それはあくまで「本発表のAnswer」と念押ししている点に好感を持てた。

実装上の都合でユニットテストを導入しづらい状況のプロジェクトも多い一方、テスト技法に関する様々な手法や主張は初学者を萎縮させてしまうことが多い。観点に応じて異なるAnswerとなることに多くの時間を割いて説明している点が素晴らしかったと思う。

2年かけました!大規模サービスをJava製CMSからPHP+Laravelの構成にリプレイスし、運用している話 / Motoki Hirao

課題や運用など多くの観点で「プロプライエタリからオープンへ」の典型的な例だと感じた。

移行前システムは有償ライセンスの製品で、それにより次のような問題が発生していたとのこと。

  • ライセンスの制限によりローカル環境の構築を行えない
  • データベースが独自実装でGit管理が不可能
  • サーバとCMSとが密結合しており柔軟なスケール対応が困難
  • ログ調査がgrep等を用いた「熟練の技」になっている

社内の業務システム等であれば大きな問題とはなりにくいが、今回は不特定多数のユーザー(求人サイトの求職者)が対象だ。状況はかなり深刻だったのだろうと想像した。

これをOSSベースのシステムに切り替えることで次のようなメリットを得られたという。

  • アプリケーションをコンテナ化し環境構築やスケールを容易に。
  • ログを分析用SasSへ転送し運用やトラブルシューティングを容易に。
  • 全てをGit管理しパイプラインを活用。デプロイの簡略化やテストの自動化。

移行の目的を「古いから新しくしたい」など漠然と捉えてしまうとおそらく上の選択肢にはならない。

Webサービスは変わり続ける、それに対応できるシステムを作りたい、そういった意志がないとこのドラスティックな変更には踏み切りにくい。2年をかけた移行の中には次のような作業もあったそうだ。

  • 予定機能の実装を終えた後、セキュリティテストと並行で新システム実装中の旧システムへの追加機能を実装。
  • それらを終えてから更に、総合テストや受け入れテスト。
  • 旧システムとの現新比較として手動での数万件のテストを実施。
  • リリース後対応として、全員がかりでアラートや問い合わせへの対応し1,2週間で全て潰す。

確固たる意志を持った上でないとできない決断と進行だ。

発表の後半ではPHPやLaravelのバージョンアップが喫緊の課題となっていることに触れた上で、リプレイスを終えてからが本当の始まりと締めくくっていた。Webサービスはそもそもそういうものだと言うのはもはや常識になりつつあるが、目的を正しく捉えていたからこそ成し遂げられた仕事だと思う。拍手。

オンプレミスからパブリッククラウドへのサービスマイグレーション / @rhack_commerce

前半がクラウド移行、後半が「楽天競馬」のパフォーマンス対策の話だった。

クラウド移行

リプレイス案件ノウハウ集大成トーク、と言った内容だった。

これまでの経験の中で自分が実際に行ったり検討したりした手法は一通り紹介されていた気がする。加えて楽天のような大規模サービスならではの課題や困難を克服するための手法なども惜しみなく紹介され、本当に無料で聴けて良いのかと感じてしまう内容の濃さだった。

  • 事業部からの要請でパブリッククラウドへの移行が必要となった。
  • Symfonyの既にEOLを迎えたバージョンを利用していたため置き換えが必要だった。
  • 移行後のFWとしてLaravelを採用することにした。

クラウド化のはずがリプレイスに話が膨らんでいる。

  • 移行対象の利用有無や利用元を調査したが把握できないサービスが幾つか出てきた。
  • 対象のコード調査や運用フロー(マニュアル)の洗い出しから情報を収集した。

不明システムの調査案件まで入り込んできている。

当初の要請を大きく超えたことをやろうとしているのだから困難は当然だが、EOLやブラックボックスはいつか解決しなければならない問題だ。クラウド化と同時にリアーキテクチャまで行うのは合理的だと思う。自分が当事者だった場合も同じ判断をするだろう。

  • 当時、Laravelを知っている人がチームにいなかった。

どうして採用したのだと突っ込みたくなったものの、紹介された各機能のリプレイス手法を聞くとLaravelや周辺ライブラリの機能を有効に使いこなすことで困難を乗り越えている。チームメンバーの特に情報収集の練度の高さを感じた。

  • ログイン機能は Laravel Socialite で容易に実装できた。
  • Salesforce連携も同じくSocialiteで実装。
  • CacheやQueueが大変便利なのでそれをフル活用。
    • QAチーム用にバッチを管理画面から任意実行する機能を実装。WebインターフェースからバッチをQueueに投入する仕組み。
  • 稼働中システムの新機能はComposer Scriptとして取り込む仕組みを実装
    • Laravelを使う時点でComposerは確定なのでそこで巻き取るのが合理的
    • LaravelであればService Provider等による拡張も容易なのでそれも駆使
  • 移行対象は1600画面160バッチ
    • 移行前コードから移行後への置き換えは正規表現置換などを駆使

何れも簡単に紹介されていたのみだが、どれもそこそこ高度な知識や旧システムの理解が必要のはずだ。チームの優秀さを感じた。

アプリケーションの移行のみならず、実際の移行でも様々なテクニックが使われていた。

  • メール配信
    • IPアドレスのレピュテーション対策のため実際の移行よりも3ヶ月前倒しで徐々に行った。
  • NFSの移行
    • 閉域網で自社とクラウドとを接続しrsync転送、但し実サービスに影響を与えないよう帯域利用は抑制
  • データ移行(データベース・NFS)
    • 前日までに一通りのデータを移行しておき、当日は更新データのみ移行する。
    • 更新データ抽出のパフォーマンス施策としてupdated_atカラムに予めインデクス。本番へ影響を与えないようSlaveへ構築。

これらの準備のおかげで当日のダウンタイムは5時間で済ませたそうだ。この5時間のためにどれだけの時間を費やしたのだろうか。素晴らしい仕事だ。

楽天競馬で実施している負荷対策

地方競馬のネット投票サービスとのことで、投票締め切り直前や結果発表直後のスパイクアクセスが話題の中心。観る前から予想してはいたが、内容は予想を超えたものだった。

  • 公営競技の公平性という観点より開催中の稼働率は100%を求められる。
  • 開催中の障害が発生した場合は監督省庁から指導が入ることも。

そうでなくとも「当たり馬券を書い損ねた」等の真偽不明のクレームがひたすら来るかもしれないことを考えると、想像しただけで身が引き締まるサービス要求だ。

セッション中にトラフィックのグラフが示されたのだが、かなりやりづらそうなパターンに思えた。

  • 投票時間中
    緩やかに上昇しながら継続し締切直前にピークを迎える。
  • 投票締切後
    一時的に激減する。
  • 結果発表直後
    締切直前を超える水準まで瞬時にスパイクする。

瞬発的なトラフィックと長時間継続するそれとでは対応のアプローチが異なる。短時間でそれらが交互に来るというあまりにも変則的な傾向だ。

レースの際は本館環境の負荷を計測し同じ状況を作る負荷試験環境を構築。そして改善やリリースを繰り返しているとのことだった。SREチームの方々は相当苦労しておられると思う。引き続き頑張ってください。

フレームワークの機能を使わずに標準関数使ったら障害起こした話 / @asumikam

前半は障害とその原因の話、後半は組織としてそれらにどう取り組むかの話だった。

前半の障害の話。本来はFWに任せるべきグローバルな入出力をPHPの標準関数(今回は header() )で直接行っている箇所があり、それが災いしコード修正とは別の箇所が壊れるというパターン。

比較的よくある原因だと思うが、これらは「怪しい箇所を試しに修正してみたら直った」「FWの『お作法』通りに書き直したら直った」等で済まされてしまうことが非常に多い。(そして忘れた頃に別箇所の同じ原因で再発する。)

ところが登壇者は、FWのコードを読み、障害の発生するケースと発生しないケースとで処理の流れを追い、FW内部で使われている標準関数の正確な仕様を調べ… ここまで行い言語仕様のレベルで原因を正確に特定していた。手掛けている製品や自分たちの書いたコードときちんと向き合う姿勢があってこその行動、素晴らしいと思う。

後半の組織や制度の話。素晴らしい話だったのと同時に、自分にとっては耳の痛い内容でもあった。

  • 今回の障害、早期に対応できたのは「障害対応フロー」を作成していたから。
  • 障害対応は情報が錯乱しがちで、対応の足並みが揃わないことも多い。
  • そんな中、知見のある人が 素早く解決してしまう
    • 知見の共有がまばらになる。
    • 障害を発生させた人が 自分を責めてしまう

障害の程度にもよるが、多くの場合私は 素早く解決してしまう 側に回ってしまう。チームの練度が上がらない問題点は認識しつつもステークホルダーへの損害との天秤と考えていたのだが、当事者が自分を責めてしまうなどの要因は見過ごしがちではっとさせられた。

  1. 障害対応フローの最初で、各メンバーの役割を決める。
  2. 対応した内容を時系列でまとめる。
  3. 対応が完了した後、対応の「振り返り会」を行う。

対応フローは以上のような内容だが「障害対応」のハードルを下げるために各所で様々な工夫が込められている。

  • 障害が疑われる場合、Slackbotにより周囲にそれをすぐに連絡や相談できる仕組み。
  • 障害と認識された場合、自動的に対応チャンネルが作られる。
  • 「障害対応ガイドブック」の冒頭には「焦らないで!!」と大きく記載。
  • 対応の冒頭で役割を決定する際は、基本的には慣れていない人を優先的に採用。
  • 「振り返り会」の心構えも明記。批判しない、原因を掘り下げる、実現可能な恒久対応、など。

是非とも参考にさせてもらいたいと思った。

Modularising the Monolith / @avosalmon

モノリシックなLaravelアプリケーションをモジュラモノリスへ移行する話。

個人的には圧倒的ナンバーワンなセッション。Laravelアプリケーションのリアーキテクチャを題材としていたが考え方自体はLaravel以外を含む多くのアプリケーションに適用できる内容だった。設計に悩んでいる人は是非とも観て欲しい。

前半は「モノリス」「マイクロサービス」「モジュラモノリス」の説明。それぞれのメリット・デメリットが解りやすく端的に語られた。

好感が持てたのは「モノリス」の利点をきちんと紹介していた点。時流に乗りたい盛りの新規プロダクトで様々なパターンをつい導入してしまい、オーバーエンジニアリングになったり後になってコンテキスト上の不備に気づいてしまうことが多いと感じている。

設計の導入は用法用量も重要なので、それを紹介する話などは両論併記ではないが様々な観点からの比較検討されていることが望ましいと思っている。概要として次のようなことが語られていた、

  • モノリス
    • 特にサービス初期はスピード重視ならこれが有利
    • リポジトリ、パイプライン、インフラ、それぞれシンプルに保てる
    • トランザクションの実装を複雑化させずに済む
    • 変更の影響範囲がアプリケーション全域に及ぶためスケールが難しい
  • マイクロサービス
    • 変更の影響範囲はサービス内に閉じられる
    • 個別にスケールアウトが可能
    • それぞれに応じた技術スタックを採用可能
    • オーバーヘッド、トランザクション、サービスを跨ぐ設計変更などの点で不利
  • モジュラモノリス
    • アプリケーションは単一のためオーバーヘッドは少ない
    • コンテキストの境界を明確化しやすい
    • 設計変更のコストは比較的低い
    • モジュール毎のスケールアウトや個別ビルドは行えない

この設計をLaravelへ適用するやり方も説明された。私にとってはここが一番有り難かった。

  • モジュール分割後のディレクトリ構成の例
  • Laravel標準構成を外れることにより必要となる対応
  • 個別のモジュールをサービスプロバイダという形で一元管理する手法
  • それらを踏まえたテスト設定(phpunit.xml例)

主に必要となる一通りの対応がコード例と共に示されていた。すぐにでも導入できる精度だったと思う。

更に各モジュールでの実装の方法論にも触れられている。

  • モジュールには外部からそれを参照してもらうためのContractを定義
  • モジュール間で実装を直接参照することはせずContractのみを通してコミュニケーション
  • Contractだけでは対応できないデータの受け渡しはPOPOで実装されたDTOを経由
  • 又はあるモジュールのイベントを別のモジュールからListenしても良い
  • モジュールをまたぐ実装の参照はテストであっても行わない
  • 外部キー制約は境界をまたぐモデルを密結合させることになるので使わない

そうは言ってもモジュラモノリスなのでモジュールを跨ぐ参照も実装しようと思えばできてしまう。それを静的解析で禁止するアイディアが紹介された。

  • Deptrac でアプリケーションやモジュールをレイヤーとして設定する
  • あるレイヤーから別のレイヤーへの参照の許可や禁止を設定しCIで静的解析

採用有無の検討から設計、基盤の実装、実際の実装、一通りに対応できる内容だったと思う。次に何か新しいプロジェクトに着手する際は再度見返して頭に入れてから臨もうと思う。感謝。

導入から 10 年、PHP の trait は滅びるべきなのか ーーその適切な使いどころと弱点、将来について / @sji_ch

凄まじい情報量のマシンガントークだった。

「滅びるべきなのか」というテーマに対する登壇者の考えや主張を想像していたがそうではなく、オブジェクト指向原則を始めとした様々な「設計のあるべき姿」をひたすら引用しつつtraitはそれに合致しているかをひたすら評価していくような内容。フレームワークや実際の業務コードでの実装例なども折に触れて例示されていた。

この25分のためにどれだけの時間を情報収集に使ったのだろうか、又はどれだけの知識をお持ちなのだろうか。驚愕してしまった。

評価の前置きとして良いことを仰っていたと思う。「良し悪し」は状況や目的に応じて変わる、であれば「良し悪し」を「合目的性」と言い換えても良いのではないか。この考え方が素晴らしいと感じた。当たり前のことなのだけれども、普段つい忘れがちだったりもするので意識していきたいと思う。

PostgreSQL + TimeScaleDBでログ管理検討 / Satoru Yamauchi

PostgreSQLしかも パッケージ拡張 の話題。パーティショニングテーブル の話が出てきた辺りからPHPカンファレンスだということをすっかり忘れ #pgunconf 辺りに参加している気分になってしまっていた。楽しかった。

PostgreSQLユーザーでなくとも、ひいてはアプリケーションエンジニアであっても応用できる内容だったのが良かったと思う。

TimeScaleDBは要するにログなど時系列データの過去データを「圧縮(実装的にはサマライズやグルーピング)」することで容量を削減する機能のようだが、ログテーブル中の一定期間経過した過去データはgroup by等でサマリして別テーブルに退避する実装をしたことのある人は多いと思う。それを「汎用的に」やるにはどうすれば良いか、などのヒントになると思う。

アプリケーション側で実装するとパフォーマンスや安定性に不安が残るような機能の場合もDB側に少し手を加えるだけできれいに解決するケースも多い。このセッションでDBやPostgreSQLに興味を持たれた方は、是非ともDBの世界にも入門してみて欲しい。