トーク

トラブルの耐えない決済システムをPHP×Laravelフレームワークでリプレイスするにあたって、どのような課題に対して、どうやって改善したかをお話します。

前半20分は、リプレイス後の決済システムのしくみについて、後半20分は、20万レコード更新を同期処理で実現したことについて、弊社DBAのyoku0825さんと感想戦をします。

※ 以前にタガヤスという技術勉強会でお話した内容の改訂版です。

普段我々が使っているコンピュータシステムというのは、階層的なシステムです。

物理法則から電気回路が作られ、ハードウェアが作られ、ハードウェアの上で動くファームウェアや OS があって、更にその上で動くアプリケーションがあって、アプリケーションの中でも C 言語で書かれた PHP 処理系、更にその上で動く PHP で書かれたスクリプト、というように、何重もの階層化がされています。
土台になるものから高く階層を積み上げていく、というイメージで、階層の上のほうにある技術を高レイヤー、下のほうにある技術を低レイヤーと呼んだりします。

PHP のスクリプトというのは比較的高レイヤーに属するプログラムなわけですが、PHP コードがコンピュータ上で実際にはどう振る舞っているのか、どういう仕組みでできているのか、というのは、当然より低レイヤーの技術で成り立っています。

今回のセッションでは、そんな PHP より低レイヤーの世界へ FFI を通じて PHP スクリプトからアクセスし、PHP 自身から階層をぶち抜いてスクリプトの動作を下の方から覗き見てみるという、少しひねくれたことをやる自作のツール、php-profiler についてお話します。

雑に言うと PHP で ELF と procfs と ZendEngine の内部構造体をパースしつつ FFI で外部プロセスのメモリを読み取り、スクリプトの動作を盗み見るお話です。

令和の世においても根強く利用されるデータフォーマット『CSV』
他サービスとのデータ連携やバルクデータ入出力などで使い勝手が良いため、未だに大活躍しています。

ですが、PHPでは扱うための癖が強く「微妙にダメなのは判っているけど諦めて使っている」「そもそも絶対におかしくなるので編集してから利用、または入れてから編集している」などのつらくきびしい現実がありました。
また、一般的には「変換不能文字があると行ごと無かったことにするiconvストリームフィルタ」や「メモリが枯渇しやすくなるmb_convert_encodingを用いた対応」など、一見安全に対応できたように見えて運用面で深刻な問題を抱える対策が蔓延っています。

このトークではそんな現実と対決し「ダメだと判っていたそれを解決」「そもそもおかしくならないのでゼロストップでデータ入出力」できる方法をご紹介します。

人は言います——モジュールを疎結合にせよ、と。
人は言います——具象ではなく抽象に依存して実装せよ、と。

ソフトウェア設計におけるベストプラクティスは異口同音に関心の分離の重要性を説きます。SOLID原則の「D」ことThe Dependency Inversion Principle / 依存性逆転の原則を実装するための道具立てとしてDIコンテナ、あるいはIoCコンテナと呼ばれる仕組みが利用されることがあります。

「PHP DI」などで検索すると、さまざまな説明が読めることでしょう。……御託はわかった。しかし昔の私には問題意識も活用方法も理解できず時間は過ぎ去っていきました。フレームワーク嫌いの私も数年も経験を積み、いくつかのフレームワークに触れてそれぞれの長短がわかってくると「Laravelのこれだけ使いたい」とか「CakePHPのここだけ羨ましい」などと考えはじめるものです。

このトークではPHP-DIに触発された簡易的なDIコンテナの実装方法を紹介し、PSR-18のような外部と通信するインターフェイスを分離しオブジェクトの生成をDIコンテナのオートワイヤリングに任せることで、どのように実装を簡潔にできるかを説明します。発表内容は実装にフォーカスしており、設計原則やソフトウェアアーキテクチャについては言及しません。

今回の発表では以下のコードの実装時に得られた知見を含みます。

• 特定のフレームワークに依存せずPHP-DIを用いてオブジェクト生成とメソッドのディスパッチを行なったWebアプリケーション
  https://github.com/phppg/phperkaigi-golf
• リフレクションを用いてメソッドを動的ディスパッチするライブラリ
  https://github.com/bag2php/meta

2020年の10月に「Fukuoka.php Vol.32」という勉強会で Laravel Livewire のデモを発表する機会をいただきました。

概ね好評だったのですが、一部の方から
「キモい」
「ヤバイ」
「怖い」
「負荷で死にそう」
「次世代jQuery」

という感想もいただきました。これらの危惧を払拭すべく個人プロジェクトではありますがLaravel Livewireを使用したアプリケーションを作成しました。

作成したアプリケーションを例に Laravel Livewire の使い方、内部ではどのように動いているのか、作成時に気をつけたことなど説明します。

Laravel Livewire は決して怖くはありません！！！！

※ PHP カンファレンス 2020 でお話した内容の改訂版です。図表が増えたりデモを失敗しなくなったりします！

PHP は "PHP: Hypertext Preprocessor" の略ですが、この 25 年間で Web は高度化し、複雑化し、それに伴い Web サイトを作るための言語にも、いっそう複雑な機能が要求されるようになってきました。

昨年リリースされた PHP 8 では、満を持して JIT コンパイラ が導入されました。

典型的な PHP アプリケーションは I/O バウンド（DB バウンド）です。JIT はそのような既存のアプリケーションのためというより、これまで PHP が使われてこなかった、使えると思われてもこなかったような、新たな領域への扉を開くものとして、FFI や Preloading との組み合わせを念頭に提案されたものです。

一方、世間の CPU は着実に多コアの時代へと進んできました。今の時代にある程度 CPU を使うアプリケーションを作ることは、JIT を使うだけの話では済まず、何らかの並列処理機構を用いこの多コアの CPU とも向き合う必要があります。

このトークではそんな新時代における PHP を使い、

• FFI でシステムコールを呼び出し外部プロセスのメモリをのぞき見たり
• （非 Web の） GUI ライブラリを利用してデータを可視化したり
• ext-parallel によりプログラムをマルチスレッド動作させたり
• スレッドの動作効率化ため preloading を活用したり
• JIT によりそのようなプログラム全体の動作を高速化したり

といった、一味違った PHP の利用方法への挑戦を紹介するとともに、そこで得られた知見、現状の制限についてお話します。

サービスが成長し、機能が追加され、データ量が増大してきたある日、サービスが速度面で劣化してきます。そのような状況ではウェブアプリケーションの処理速度を改善するためのチューニングが求められます。しかし、チューニングの経験がない場合、何をすべきか分からず、効果のない改善作業を繰り返してしまいます。本トークでは実際の例を参考にして、どのようにウェブアプリケーションのチューニングを行っていくべきなのかを丁寧に解説します。

このトークでお話すること

• アプリケーションが遅いとは？
• 問題の特定方法
• レイテンシーの評価
• チューニングを行う判断基準
• ケーススタディーで学ぶ「実際のチューニング」

あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。
いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減（PHPerKaigi2020で発表）」は継続的な生産性向上のためには考えなければならない要素です。
そして、上記を補完するためにしばしばドキュメントが書かれます。

私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。
私はこれを「Documentation as Code」と呼んでいます。そして、そのような概念はすでに世の中にあり、時として「Documentation as Code」と呼ばれているようです。
例えばPHPDocなどはソースコード自体の構造とアノテーションをトレースしてドキュメントの自動生成を実現しています。
OpenAPIのように構造化されたデータとして情報を記述することでドキュメントと同時にAPIクライアントやの自動生成が実現できている例もあります。 これらはコードによってドキュメントが管理されており、継続的なドキュメンテーションも実現可能です。
さて、ドキュメントと言っても「何を解決するためのドキュメント」なのかを考える必要があると思います。
本発表では、上記のような「Documentation as Code」を実現するツールを独自にモデル化してそれぞれの特性について考えます。
そして、どのような「Documentation as Code」が「開発開始までのオーバヘッドの削減」に繋がるのか、私が実際に取り組んだ（また取り組んでいる）事例を交えて考えていきたいと思います。

• とある企業でDBAを務めていますが、お手製の監視スクリプトをytkitというスクリプト群としてオープンソースで公開しています
  • https://github.com/yoku0825/ytkit
  • 一番使っているのが監視スクリプトである yt-healthcheck というやつです
• コイツはまあ、Perlで書かれてるんですが、これを見ながら「本職のDBAはこんなこと考えながらMySQLの監視してるんだな」という紹介です
  • いいじゃないですか、変数名の頭に$がつくPで始まるもの同士仲良くしましょう！
  • なお、私のPerlはへたっぴです。監視用のSQLだけは自信があります。

• MySQL InnoDB Clusterという比較的新しい、公式のHAソリューションがあります
  • 今までの(非同期/準同期)レプリケーションに比べると圧倒的にデータの不整合に強い
• 利用開始は非常に簡単、PHP側からは透過的に単なるMySQLのように見えます
  • Group Replicationというmysqld側の技術と、mysqlrouterプロセスが連携して動きます
  • Group Replicationの設定変更はMySQL Shellから操作するのが圧倒的に楽です

しかし流行っているように見えない！
使えるところには使えるソリューションだと思いますので、これを機に勉強してみませんか？

• セットアップの方法
• Group Replicationの仕組みの説明
• mysqlrouterの仕組みの説明

明日から使えるLaravel Livewire

VueやReactでしっかりしたフロントエンドを構築できていますか？　もしいろいろな事情でまだできていなのであれば、Laravel Livewireが第三の選択肢になるかもしれません。

Livewireを使えば、サーバサイドのコードだけで、リアクティブなフロントエンドを実現できます。

このセッションでは、リアクティブプログラミングの概要から、具体的にLivewireで実現できる「便利さ」まで詳しくご紹介します。

LTしたことある人、挙手。
カンファレンスで登壇したことある人、挙手。
本書いたことある人、挙手。
何かアウトプットしていますか？Twiterやブログだって十分です。

登壇や執筆なんて、つよつよエンジニアだけができるものだと思ってませんか？違いますよ？もっとカジュアルに登壇・執筆・アウトプットしてみましょう。

トークに自信がない？ネタがない？自分なんて初心者だから？そんな幻想・呪縛はポイです。あなたの「今」を切り取ったアウトプットをしてみましょう。必ず誰かが聞いてくれます。必ず誰かの役に立ちます。そして自分も得るものがあります。必ず次につながります。

アウトプットの始め方、育て方、広げ方、トークネタの作り方、そのあとの広がり、やってうれしかったこと、などなど。

やってみようかなと思った時がはじめ時。アウトプットをはじめることで開ける優しい世界の一端を紹介し、あなたをアウトプットの世界にお誘いします。

PHPerの皆さんは、日々Webアプリケーションを開発している中で、フレームワークのコードと自分たちのコードを区別できていますか？
自分たちのアプリケーションにとって重要な、業務知識をモデリングして書いたコードは、「いまのフレームワーク」と切り離して動かすことができるでしょうか？

フレームワークのバージョンアップ、あるいはフレームワークの開発終了によって自分たちのアプリケーションの命運が左右されることがないように、フレームワークへの依存を取り除き、大事なコードの可搬性を高めましょう。
ごく一般的な小さなWebアプリケーションを題材に大事なコードを守りつつLaravelからSymfonyにフレームワーク変更する様子を実演しながら、考え方とテクニックについてご紹介します。

「ママリ」を運営するコネヒトは2020年12月にConnehito Tech Visionとして「Beyond a Tech Company」というビジョンを公開しました。本セッションでは、なぜテックビジョンをつくったのか？そもそも、テックビジョンとは何か？といった話から、技術のコモディティ化が進み、アフターデジタルな世界の実装が進む中で、今後開発組織はどうあるべきか？どういった技術戦略が求められてくるのか？といったお話を出来ればと思います。本セッションとこのテックビジョンの紹介を通じて、一つの開発組織の在り方を提示したいと考えています。

弊社のシステムはバックエンドのフレームワークは Laravel を使用、そして OpenAPI と呼ばれる API の設計書を書けば CRUD に対応した API が自動的に実装されるような仕組みを用いて自動生成し、最後にバリデーションを書けば、一つの API が完成します。
もともと弊社の社内システムは SaaS 上にしかなかった、かつバックエンドエンジニアが私一人である中で、どう効率的にゼロベースからプロダクトを組み上げてプロダクトのローンチを早められるかが鍵でした。
CRUD に対応した API 実装、正常系・異常系テストの生成自動化、API のドキュメントの記述、全文検索エンジンへどう自動的に繋ぎこむか、例外処理はどうするか？といった全ての事情を汲み取りながら基盤開発に邁進し、
今では一つあたりの API の実装は 10 分もかからないレベルになりました。本トークでは、この基盤の構築をした経験を元に、考えてきた事、実行してきたこと、判断に迷ったこと、そして Laravel を使った実装についてのお話をできればと思います。

待望の PHP8 が出ましたね！
パッケージマネージャーで PHP をインストールすることが多い昨今、ビルドって実際にどうやるんだろう？と疑問に思っている方も多数いらっしゃると思います。
敷居が高そう、難しそう、そう思っている方もいらっしゃると思います。しかし本当は PHP そのもののビルドはそんなに難しくありません。
ということでトークの時間を目一杯使って PHP8 のビルドをオーディエンスの皆様と一緒にライブ形式でやってみたいと思います。
本トークで、ビルドをどうやるのか感覚を掴んでいただき、ぜひ様々なシーンでご活用できるようになっていただければと思います。

ソフトウェア開発において、不確実性にどのように立ち向かっていくかは大きな課題です。
PHPerとしては、開発中にいかにコード品質を上げるかといったことは大きな関心で、その一つの規律のとり方としてTDDを実践されてきた方は多いのではないでしょうか。

トークの表題であるATDDは、Acceptance Test Driven Developmentの略です。TDD Cycleよりももう一つ大きなスコープでのフィードバックループをテストによって駆動します。特にアジャイル開発の文脈で「Agile Testing」という一つのテーマ内で紹介されることが多い手法です。

ユニットテスト・コンポーネントテストをカバーするテストによって開発を駆動するTDDに対して、ATDDはよりビジネスフォーカスの強いテストによって開発を駆動します。ATDDの開発プロセスの実践によって、技術レイヤ横断的な製品全体の回帰テストの整備につながり、直接的な顧客価値となる外部品質の明確化・維持・向上が期待できます。

このトークでは次の内容について話します。

• ATDDとはなにか、Example-driven Developmentの考え方
• 前提となる「Agile Testing」の考え方
• ATDDを実践する開発プロセス
• テスト自動実行基盤の構築プロセス・構築例
• ATDDを実現するツール選定とツールを用いた「受け入れテスト自動化」
• エンドツーエンドなテスト構築（APIサービスとブラウザベースサービス）
• TDDからATDDへ、自動化テストピラミッドを登っていく

内容は特定技術の実装からインフラ・CI基盤、開発文化・プロセス自体と多岐にわたりますが、ソフトウェアテストという側面で開発を駆動させるあり方として参考にしていただければ幸いです。