皆さんはDaemon(デーモン)をご存じですか?Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。
このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー(systemdやコンテナ)との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。
もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。
単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも(あるいはそうでないあなたも)、この機会にDaemonを造り、飼いならしてみませんか?
皆さんは Joe Watkins さんをご存知でしょうか。
PHP コア開発者の一人で、インターネット上ではしばしば krakjoe というニックネームで活動しています。
ご存知ない方は、以下いずれかの PHP 拡張や SAPI のお世話になったことはありますでしょうか。彼はこれらの拡張や SAPI の作者です。
・apcu
・pcov
・phpdbg
・parallel
・pthreads
また彼は PHP Foundation 設立のきっかけとなった一人でもあります。
ここ最近のバージョンの PHP を使っている人は PHP Foundation の雇ったコア開発者の仕事の恩恵を得ており、つまり最近のバージョンの PHP を使うだけでも、間接的にですが krakjoe さんの取り組みから少しばかりの嬉しさを得ている、と言えます。
彼は現在、健康上の理由・経済的理由から危機に瀕しており、gofundme にて寄付を募っています。
https://www.gofundme.com/f/a-big-ask-from-a-big-community
この記事では krakjoe 大先生がまた元気になってよく分からないものを沢山作って、世の中や PHP 界隈を賑やかにできるよう、その偉業をたたえつつ寄付を煽っていきたいと思います。
昨今、開発の中にコードレビューのフローが存在するチームは多いのではないでしょうか。
そして、そういったチームへのジョインや会社への入社したエンジニアは、いつかコードレビュー1日目を迎えることでしょう。
特に、自分自身のスキルに自信がない方は、
・ 他の先輩方のコードレビューをするのは気が引けるな・・・
・ 自分はスキル的にまだまだだから、コードレビューなんてまだできないよ・・・
・ いざレビューしてみてるものの、なんてコメントしたらいいかわからないな。。
・ 自分はLGTM( = Look Good To Meの略。自分的にはOKという意) と思ってLGTMにしたけど、他の人がめっちゃコメントしてる・・・
のようなネガティブな考えに囚われてしまい、気付けばLGTMしかコメントしなくなっていたり、誰かがLGTMとコメントした後に自分もコメント残しておこうみたいなマインドにもなってしまいます。(新卒時代の僕がまさにその状況でした。)
本セッションでは、自分自身が思考錯誤して見つけた「自信を持って最初の1歩を踏み出す方法」を紹介します。
・ これならできそう
・ そんなに難しく考えなくていいんだ
と思っていただけると嬉しいです。
新たにチームにジョインする方が新しい環境にも臆さずコードレビューできるようになったり、
チームに招き入れる側の方が、新人に対して安心させてあげられる状況作りの1つになると幸いです。
新卒1年目の僕のような状況に陥ってしまう方が1人でも少なくなりますように。
対象者:コードレビューの体制のあるチームの全エンジニア(役職問わず)、これから新卒として入社を控えるエンジニア志望の学生の皆様
昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。
しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
逆に言えば、伝え方次第ではRevieweeが自信を持たせたりコードレビュー依頼を活性化させることもできるようになります。
本セッションでは、Revieweeのやる気を促進させつつ、レビューも行っていく方法を紹介し、PHPerエンジニアへのヒアリングも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。
対象者:コードレビューを行う全エンジニア(役職問わず)
PHPの、新しいExtension Installer・・・PIE!
php/pie: The PHP Installer for Extensions
そして、このツールで導入できる拡張たちは、Packagist上で検索やメタ情報の取得ができます。
・・・となれば、興味が湧くのは「ここで、どんな情報が扱われているのか」ですよね✨️
また、従来からPackagistで扱われていたComposerパッケージのそれとは、なにか違うのでしょうか?
更に言えば、ここで取得された情報は、どんな役割を果たして、PIEによるインストールのプロセスに役立っているのでしょうか??
この記事では、「PIEをどう使うか」「どう活用・運用していくか」といったトピックには重きを置かずに、
「レポジトリ(Packagist)の提供するAPIとして、どうなっているの?」といった内部事情・詳細部分にフォーカスを当てた、
ちょっとニッチな話題を扱います。
設計に詳しくなりたいし、設計力が欲しいし、色々な場面で良い感じな設計を描けるようになりたいですよね。
ソフトウェアづくりに設計は必要です。
何をもって「良い設計ができた」と言いますか?何を目指していますか?
本トークは、その自信と根拠を持つための、「なぜ設計を行うのだっけ」を考えるきっかけとなることを目指します。
PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか?」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか?
例外の種類や扱い方が曖昧だと、設計の混乱やコードの保守性低下を招きます。この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。
Result型は、失敗が起こり得るということを型として扱い、例外に頼らずエラーを管理する手法です。これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高めることができます。このセッションでは、Result型をPHPに応用する方法を実装例を交えて解説します。
取り上げる内容:
例外の扱いをもっと明確にし、エラー処理を改善するヒントをお持ち帰りください!
ScalaやErlangなどでアクターモデルは、1973年に発表された並行計算の数学的モデルの一種ですが、
長い間PHPでは実現が難しいとされてきました。
アクターモデルは、並行プログラミングにおける効率的な計算モデルであり、プロセス間の非同期通信も特徴の一つとしています
効率よくそれぞれが並行で動作し、簡単に状態を復元することができたりPHPのOSSなどではあまり見ない特徴を持っています。
PHPでももしそれが実現できたら・・・
しかし時間が経つにつれ、Swooleなどをうまく活用することで実現できそうなことがわかり、
PHPでフルスクラッチで開発したアクターモデルのツールキットがPhluxorです。
Phluxorは、PHPではあまり見られないメッセージングを活用した仕組みを持ち、
各インスタンスが独立して動作し外部から隔離されたアクターを実現しています。
さらに、物理的に異なるサーバ間でのアクター操作が可能な機能を実装しています。
Webフレームワークとは異なり、情報伝達設計に特化した仕組みを持ち、
PHPでは他に類を見ないヒエラルキー構造や自動復旧機能でアクターシステムをサポートしています。
これらは一体どのように実装して、どんな仕組みで動いているのか?
アクターモデルのツールキットの作り方について、詳しくお話します!乾杯!
皆さん、ちょっとしたコードの動作確認をしたい・サクッとRDBを参照/書込する作業をしたい、等の場合に何を使っていますか?
コードを対話式で実行できるREPL(Read Eval Print Loop)は書き捨てのスクリプトを作ったりせずにコードを実行でき、開発を大いに助けてくれます。
PHPではphp -aコマンドで起動されるランタイム同梱のインタラクティブシェルや、より高機能で補完機能やコード実行結果の自動出力機能などを備えたPsySH (bobthecow/psysh)などがあります。
また、laravel/tinkerやcakephp/replなど特定の用途向けに作成されたREPLも存在し、筆者は簡単なRDBの読み書きであればREPLから行うこともあります。
実はそれらのREPLはPsySHをベースとして開発されています。
そんな便利、かつ他のツールの基盤となっているPsySHはPHP製のOSSです。
そう、PHPerが普段使い慣れた言語で作られているのでコードを読めば仕組みがわかります。
この発表では、REPLの基本である「入力の読み取り (Read)」「評価 (Eval)」「出力 (Print)」を軸に、PsySHがどのように実装されているのか・laravel/tinkerなどがどのようにPsySHを拡張しているのかを深掘ります。
みなさん、ドメインイベントって使っていますか?
このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。
ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルです。注文の完了やユーザー登録のようなビジネスプロセスの特定の状態変化を表現できます。
これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。
ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ!」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします!
話すこと
API Platformという、APIを作るためのフレームワークがあります。
便利なフレームワークである反面、引き換えに犠牲を伴うことが多くありますが、
その話題がのぼるほど利用者がいないのではないか…と思っています。
なので、API Platformを広めるために便利機能を見開きでわかりやすく!お伝えします。
本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、その仕様を様相論理の一種である時相論理を用いて厳密に記述し解析する技術について解説します。
みなさんは「ボタンをクリックすると機能 X が正しく動く」といったテストケースを目にしたことはありませんか? お気づきの通り、このテストケースはあまり良くない例です。では、何が良くないのでしょう? 一番の問題は、ここで言う「正しく」がどのような状態を指すのか、言い換えればこのテストケースが何を保証しているのか、が全く具体的ではない点です。
我々が何らかの方法でシステムの仕様を保証しようと考えた場合、テスト設計であるとか、あるいは自動化ツールのような、仕様を「テストする」ための方法論に目が行きがちです。しかしその前段階として、仕様を「記述する」というステップがあることは忘れてはいけません。入力に対して出力がある、いわゆる単体テストであればそれほど困らないかもしれません。しかし、例えば複数のサーバが協調して動く「分散システムの正しさ」だったら? さらに、複数のサーバのうち一部が高負荷となってレスポンスを返したり返さなかったりする状況だったとしたら、全体の動作の「正しさ」にはどのような影響があるでしょうか?
自然言語による仕様の表現は、我々が普段なんとなくイメージしている以上の曖昧性を含みます。そしてその曖昧性を排してシステムに対するより良い理解と洞察を得るために、厳密な「共通言語」を定義したいという動機は、かなり旧い時代から現在に至るまで、一貫して計算機科学の興味の対象であり続けています。
本セッションでは、このような動機に応える様相論理とモデル検査について、可能な限り誤魔化さずに解説したいと思います。普段、分散システムを触っていて、何となく計算機科学の基礎が気になってきたぐらいの方にお薦めです。
私たちのチームはPHPとRDBMSを用いた受託開発を中心に開発をしてきました
チーム文化として、クライアントニーズに迅速に応えながら、時代の変化への柔軟性を持って開発を進めることを大切にし、
常に新しい技術や手法を積極的に受け入れることを得意としていました
そんな中、話者である私自身は「サーバーレス」を得意としていましたが、そのスキルを自分ひとりの武器として振るうのではなく、
チーム全体の文化や価値観に溶け込ませ、組織的な生産性・開発価値の向上につなげるにはどうすればよいのか、日々考え続けてきました
そこで目を向けたのが「Platform Engineering」の考え方です
Platform Engineeringは、開発者がインフラやツール選定に悩まず、本質的なビジネスロジックの創造に集中できるようなプラットフォームやサービスを用意し、組織内のエンジニアリングプロセスを最適化するアプローチです
サーバーレスが得意な「私自身」から離れ、あくまで「チームとしての開発価値向上」をゴールに据え、共通のプラットフォーム基盤としてサーバーレス技術を位置づけることで、メンバー全体がその恩恵を享受できる形が見え始めました
その結果サーバーレスDBとして価値のあるTiDBもスムーズに導入出来てコストメリットを享受しています
従来のLAMP系スタックを踏襲しながらもサーバーレス環境をチームにシームレスに組み込み、Platform Engineeringという視点で共通基盤として活用し続ける価値について話します
個々人がスキルやツールに依存するのではなく、チームとして得られる付加価値、そしてエンジニアリング体験の向上についてお話できれば幸いです
運用中のPHPアプリケーションに後からCDNを導入する際、特に歴史的な経緯により、複数のカスタムドメインを使用している場合、移行作業には慎重な計画が必要です。このセッションでは、AWSのCloudFrontを例に、複数ドメインを持つ既存アプリケーションにCDNを導入する際のベストプラクティスを解説します。
まず、複数ドメインで運用している環境で効果的なCDN導入が難しい理由を整理します。たとえば、静的リソースのURLがハードコーディングされている場合や、既存のキャッシュ制御ヘッダーが正しく設定されていない場合、移行中にアクセス障害やパフォーマンス劣化を引き起こすリスクがあります。これらの課題を特定し、解決するための準備ステップを紹介します。
次に、CloudFrontを活用して既存のアプリケーションにCDNを導入するプロセスを具体的に解説します。CloudFrontのディストリビューション作成方法、複数ドメインを扱うためのカスタムオリジン設定、HTTPS対応のためのACM(AWS Certificate Manager)の証明書設定について実例を交えて説明します
さらに、移行中の段階的なテスト方法についても触れます。たとえば、特定のリクエストのみCloudFrontを経由させる設定や、デバッグ用にキャッシュを一時的に無効化する方法など、移行時に安全性を確保するためのテクニックを共有します。
このセッションは、複数ドメインで運用中のPHPアプリケーションを対象に、後からCDNを導入する際の手順と注意点をわかりやすく解説します。AWSを活用した実践的なアプローチに興味があるエンジニアの方に、移行作業をスムーズに進めるための知識を提供します。
話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています
この方法は非常に有用で、サーバーレス環境にPHPアプリケーションを載せるための標準手法として紹介してきましたが
一方で第三者が構築しているOSSに対する不安を感じる方もいるはずです
既存コードをどのようにサーバーレス化すれば良いのか、またカスタムな環境構築がどこまで信頼できるのかといった懸念があるかもしれません
特に既にLaravelやSymphonyなどのフレームワークを用いて開発されたアプリケーションを、
既存のワークフローを大きく変えずにクラウドネイティブな環境へと移行したい場合、そうした課題はより顕在化します
そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します
PHPerはサーバーレスの利点を享受しつつ、従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます
さらにLaravelに適用する際には、既存のルーティングやミドルウェア、コントローラ群をそのまま活用し、AWS Lambda上でリクエスト-レスポンスサイクルを再現することが可能です
最終的に話者がいつも利用しているBrefとの比較を行うとで、選択肢を提示します
AWS Lambdaの可能性を広げるWeb Adapterを利用したサーバーレスPHPの普及に助力出来れば幸いです
お話すること
想定聴講者
お話しないこと
クラウドネイティブやマイクロサービスアーキテクチャの普及に伴い、アプリケーションは複雑化し、
従来のモニタリング手法では原因特定が困難な障害やパフォーマンス劣化が増えています
こうした状況下で注目されるのがObservability(可観測性)です
Observabilityは、システム内部の状態や相互作用を可視化し、迅速な問題解決や改善策の立案を可能にします
本セッションでは、業界標準化が進むオープンソースプロジェクト「OpenTelemetry」を活用し、
PHPアプリケーションにObservabilityを導入する手順を段階的に解説します
Observabilityの基本概念をMonitoringとの違いを交えつつ明確化し、実際のトラブルシューティングシナリオを示します
これにより「なぜObservabilityが今必要なのか」を理解します
さらに、OpenTelemetry自体が何なのか、その本質と狙いをOpenTelemetryの特徴やコンポーネントをわかりやすく整理します
公式SDKのセットアップ、計測ポイントの挿入、外部サービスとの接続方法をサンプルコードを交えながら示し、PHPアプリへの適用ステップを紹介します
このセッションで参加者が次の開発・運用プロセスでOpenTelemetryを用いてObservabilityを導入できる一歩目を提供します
PHPユーザーであれば、日々APIのパフォーマンスと向き合うことがあるかと思います。
中でもGolden Signalと呼ばれる4つの指標(レイテンシー、トラフィック、エラー、サチュレーション)は、システムが「健全」であると判断する基準となるものです。
本セッションではGolden Signalを中心に、Performance Insightや周辺のメトリクス、モニタリングツールの操作、問題の特定や推論を可能にする為のTipsについて話します。
EC2のセキュリティがガバガバに穴が空いている状態の皆さん息してますかー?
すみません。いきなり煽りから入ってしまいました。
最近、サーバー構築作業をしている中でセキュリティ担保の方法を学ぶことがあったので、この場を借りて皆さんに共有させて頂ければ幸いです。
EC2へSSH接続を行い、サーバーでの作業を行っているバックエンド側の人の幸せにつながってくれたら嬉しいです〜
EC2のSSH鍵の扱いどうしていますか?
複数人でプロジェクトを組んでいる場合、サーバーで作業をする人が複数出てくると思います。
そうなってくると以下の作業を 作業者の人数分 × サーバーの台数分 実施しなければいけなくなります。
この時点で億劫ですね。
また、上記の作業に加えて 鍵の定期的なローテーション、チームの入退場が発生した時のユーザー管理が発生してしまいます。
死ぬほど面倒くさい!
更にセキュリティに興味が無いメンバーが存在すると、鍵のローテーションはやらなくていいじゃんとか抜かすんですよ。。あー、面倒くさい。
その問題、ECS Instance Connect で解決しましょう
EC2 Insatnce Conncetを使うと僕達ユーザーが鍵の管理をする必要がなくなるので、運用の手間をかなり減らすことができます。
(サーバー運用やったことにしか伝わらないと思いますが、管理するものを減らすという事は運用において絶大に効果があるのです!!
EC2 Instance Connect を使う際には、セキュリティグループで SSHのポート 22 を開放して置く必要があります。
22番ポートを開けるのは多少なりとも気が引けますよね〜
最低限のセキュリティ担保として、 EC2 が所属する Region のみからアクセスできるようにIP指定をすることができます。
運用負荷が下がると幸せになれます。
幸せになろう。
近年、大規模言語モデル(LLM)が急速に進化し、ナレッジグラフとの連携が重要性を増しています。LLMは膨大なデータを処理しながらも、特定分野の知識を正確かつ構造化して扱うには限界があります。ここで注目されるのがナレッジグラフ。データを構造化し、関連性を明確にすることで、LLMと補完し合いながら、より高度なアプリケーションが実現可能になります。では、PHPでナレッジグラフを扱うにはどうすれば良いのでしょうか?
本セッションでは、PHPを使ってナレッジグラフを活用する方法を解説します。ナレッジグラフとは何か、その基礎概念から始め、具体的にPHPでどのように操作・活用するかを探ります。まず、ナレッジグラフに関連するRDF、OWL、SPARQLなどを簡単に説明し、PHPでそれらを扱うためのライブラリ(例: EasyRdfやRdfPhp) を紹介します。その後、SPARQLクエリを用いてナレッジグラフからデータを取得・操作する方法を具体例とともに解説します。
さらに、PHPで構築した既存のWebアプリケーションにナレッジグラフを組み込むためのアーキテクチャ設計や、LLMとの統合方法についても議論します。たとえば、LaravelやSymfonyのようなフレームワークを利用して、ナレッジグラフを効率的にクエリ・操作し、APIを通じて他のシステムやLLMと連携するパターンを具体例で説明します。
最後に、ナレッジグラフとLLMの組み合わせによる具体的なユースケース(FAQシステムやレコメンデーションエンジンなど)を示し、ナレッジグラフの可能性を最大限に活用するための道筋を提案します。このセッションは、ナレッジグラフという新たな分野に挑戦するための第一歩となる内容です。LLM時代の今だからこそ必要とされる技術に触れ、一緒に未来のWebアプリケーションの可能性を広げてみませんか?
本セッションではTerminal IDEを、VsCodeやJetBrains製品が提供する「統合開発環境」としての機能をVimとTUIを利用してTerminal内で表現する事であると定義します。
LSP、DAP、補完やGitにDocker操作等々のIDEとしての環境をVimで構築するまでのステップと、その効率性について解説する内容になります。
皆さんに「こんな選択肢があるのか」と自分の開発環境を見直す機会になることがGoalです。
話すこと