PHP BLT #6 でphp-fpmのチューニングについてお話しました #phpblt

昨夜、2/22(水)に、勤務先のメルカリにて、PHP BLT #6が催されました。僕は、今回は発表に加え、司会をしておりました。

当日の様子: 「PHP BLT #6 #phpblt – Togetterまとめ

発表内容

結論は、php-fpmのプロセス数は固定でCPUコア数の2倍程度にセットしとくといいよ、というものです。

最近、php-fpmでPHPを実行されている人が増えていると聞きます。会場でもほとんどの方が利用経験がありました。僕は前職はITインフラ系のエンジニアでしたが、その経験を踏まえて、php-fpmをデフォルトで利用することから一歩進められるひとつのきっかけとなればと思い、今回の発表に至りました。

php-fpmは2vCPU程度の小さなインスタンスだと、正直デフォルトでもいじっても大きなパフォーマンス差は出ないことがほとんどです。しかし、開発したサービスが利用されるようになり、よりコア数の多いインスタンスにスケールアップした際、デフォルトではその性能を引き出せません。そこで、php-fpmのプロセス数をインスタンスに最適な数にセットすると、利用しているインスタンスの性能を十分に引き出しながら、処理能力を高められますというおはなしです。

実は、Web上を探すと先に僕の書いた結論をさらっと書かれている記事を見つけることができます。ただ、それがなぜなのか、という点をベンチマークツールを使って測定しながら明らかにしていくことが、この発表の特徴となっています。現場で利用されるときも、ぜひベンチマークを取って測定をしながら、最適な値を設定してみてください。

発表後に、PHPのメモリリークをどうやってケアするか、と言う話が出たので、ここで回答します。これは、プログラムを根本的に見直すのが難しい場合などは、 pm.max_requests パラメータを試しに100〜1000にセットしてみてください。これは、指定した回数リクエストを受けると、プロセスが再生成されるようになり、一旦メモリを開放することができるようになります。ただし、プロセス再生成に関わるCPU利用率があがります。

ちなみに、Wordpressの事例ですが、このブログのことです。このブログのサーバはCentOS 7系で動いていまして、ディストリビューション標準のPHPが5.4系でした(発表中5.3と言ってしまいましたが訂正します)。そのため、IUSリポジトリから7.0系を入れ直しています。7.1ではないのは、IUSにpearに関するパッケージがなく一旦やめたというのがその背景です。

勉強会について

司会をやっておりました。今までのPHP BLTのように大きく盛り上げるって感じではなかったのですが、いかがでしたでしょうか。僕がやると、淡々となってしまうところがあるかもとちょっと反省しております。

一方で、半分ほどの方が初参加、そして勉強会にあまり登壇したことがないかたが積極的にLTに参加いただけたのは、本当に良かったです。中には勉強会自体に初めて登壇したという方もいらっしゃいました。これは、PHP BLTの運営の際に、発起人であり勤務先のCTOである @sotarok さんが「多くの方に話をしてもらう機会を作る」ことがきちんと実現できたと思っており、運営スタッフの一人として大変嬉しかったです。

これからも、PHP BLTがコミュニティに参加するきっかけであれたらいいなと思いますし、自分自身もそれに貢献していくことの大切さを感じた夜となりました。

今後も、他の会社さんの会場でも開ければいいなと思っております。

その他いろいろ

勤務先のメルカリでは、今週さらに増床し(See also:「「スマオク」を運営するザワット社がメルカリグループにジョイン!東京オフィスの増床エリアも開放しました #メルカリな日々 2017/2/20」)、六本木ヒルズのほぼ1フロアを利用することになりました。その際、イベント用のスペースもリニューアル&大きくなり、このPHP BLTが外部の方に勉強会用として初めて開放したイベントになりました。

個人的にも、また何か勉強会を企画できたらいいなと考えています。たぶん、やるとしたら、ゼミ形式になると思います。

お会いした皆様、どうもありがとうございました。またよろしくお願いします。

#builderscon tokyo 2016 に行ってきました

先週末は、builderscon tokyo 2016 へ足を運んできました。YAPC::Asia Tokyoに代わって、「「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。」をテーマに開かれたカンファレンスです。

聴講したセッション

次のセッションを聴講しました。

  1. OSS は Windows で動いてこそ楽しい
  2. php.iniについて知る
  3. Open Beer Serverの理論とその実装
  4. C 言語で行う Web フロントエンドプログラミング
  5. そろそろプログラマーもFPGAを触ってみよう!
  6. 一から始めるJavaScriptユニットテスト

たしかに、テーマの通り「知らなかった、を聞く」セッションばかりでした。また、皆さんが作られているスライドの品質が高いため、無理にノートを取る必要もなく、ゆったりと聴講することができました。

同時に聞けなかったセッションも、大変興味深いものがあったと聞いています。スライドも続々アップされているようですので、改めて拝見してみようと思います。

感想

カンファレンス全体の内容として、時代に乗るのではなく、自分から時代を作っていく方ばかりだなと感じました。ここから、自分がどのようなところにアンテナを張っていくのか、きっかけになるカンファレンスになるのでしょう。

そして、自分自身で取り組んでいることを、YAPC::Asia Tokyoのときのようにまた発表したいなというモチベーションがあがってきました。次回は2017年8月に催されるとのことですので、それまでにしっかり仕込んでおきます。

運営の皆様、発表者の皆様、大変お疲れ様でした。また、お会いした皆様、どうもありがとうございました!

YAPC::Asia Hachioji 2016 mid in Shinagawa へ行ってきた #yapc8oji

記事を書くのがちょっと遅くなりましたが、7/2(土)に、YAPC::Asia Hachioji 2016 mid in Shinagawa(ヤパチー)へ行ってきました。

昨年度でYAPC::Asiaが一旦終わってしまい、様々な話が聞ける場とともに多くの方と再会する機会がなくなり残念に思っていたのですが、 @uzulla さんをはじめとした有志の方の尽力によりPはPachimonということですが多くの方が話し、交流するイベントが戻ってきました。

自分は週末のどちらかが外せなかったのですが、土曜日の聴衆枠の抽選が運良く当たり、また懇親会も無事登録することができたため、伺うことにしました。

聞いたセッション

こんなセッションを聞きました。

  • PHP 5.3.* のアプリを PHP 7.0.* で動かすためにした n 個のこと
  • あなたがエンタープライズファンクショナルPHPライブラリTeto\Functoolsを採用しなければならない11個の理由
  • コードリーディングを通じて得られたこと
  • DIコンテナ大図鑑@PHP
  • MySQL 5.7 + MySQL Fabric + MySQL Routerでぼっこぼこに {する|された} はなし
  • Browser Extension開発四方山話
  • Fluentdが新Plugin API実装においていかに自由すぎる旧APIとの互換性を確保したかの話
  • esa.io、その後の話

最近携わっている仕事の関係上、PHP関連が多めでした。特に、「DIコンテナ大図鑑@PHP」は大変参考になりました。どのような種類が存在して、実際にどのようなライブラリがあり、どのように活用していくとよいのかが体系だって説明されていて、勉強になりました。

懇親会

懇親会は近所で行われたのですが、時間があったため事前にHUBでいっぱいひっかけていく流れになりました。僕はHUBの会員カードを持っているのですが、値引きされることをいいことにみんなに使ってもらった結果、大量にポイントが貯まりましてホクホクとなりました。ここに御礼申し上げます!!!

懇親会では、YAPCや別の勉強会でたまに顔を合わせる人たちと久しぶりにお話ができました。最近は人前ではあまり酒を飲まないようにしていたのですが、気持ちがほころんでしまいスイスイと進んでしまいました。なんであんなに楽しいのかわからないのですが、とにかく楽しいひと時でした。

その後は、若手エンジニアの子たちと再びHUBでのんびりと飲んでおりました。自分はコミュニティ、特に81忘年会の縁で随分と活躍の場を広げてもらった覚えがあるので、若い人たちもそのような機会としてこういう場を使われたらいいなと思っています。

感想

この日は、自分にとって外での活動は欠くことはできないものであることを再認識できたイベントとなりました。

今年に入って、数百人規模の会社に転職してから、外の情報にあまり関心が行かなくなってしまった自分がいました。このくらいの規模になると、多くの情報が社内に飛び交い、会社の中にいるだけでも十分な知識が得られてしまうからです。こういった感覚は初めてでした。

そんな中、ヤパチーに足を運んでいろいろなセッションを聞き、そして久しぶりに会う同業の知人と話していますと、やっぱり会社の中で閉じているのはもったいないなと痛感しました。外の世界にはまだまだ知らないことはもちろん、同業の縁というかけがえのないものがあることを再発見しました。今こうして自分があるのもそういった同業の縁あってのことでした。

スピーカーの皆様、お会いした皆様、そして手弁当で活動されていたスタッフの皆様、本当にありがとうございました!素晴らしくオーガナイズされたイベントでした。そして楽しかったです!!

PHP BLT #5 で発表してきました #phpblt

昨夜、7/20にPHP BLT #5がGMOペパボさん主催で催されました。私も久々に、自分の普段の業務で得た知見をお話しする機会に恵まれ、発表しました。

発表内容

僕が現在勤務しているメルカリでは、Pull Requestのソースコードレビューはボランティアベース、それも数人の人がコメントを寄せてくれるような環境にあります。僕はこれまで小さな会社で働いていたことがほとんどで、じっくりコードを見てもらうことはもちろん、数人の人から多角的にソースコードを見てもらうことはありませんでした。そのような状況でしたから、入社した半年前は大変な衝撃を受けました。

一方で、自分がソースコードレビューをしようとした時、当初は何を見れば良いのか正直よくわかっていませんでした。そんな中で、半年の間に同僚から得た知見を元に、特に要求仕様をもとにレビューするにはどうすれば良いのか、自分なりに知見をまとめたのがこの発表になります。

要求仕様のレビューを通じて、静的コード解析では網羅できない問題を発見できることはもちろん、他の部門がどのような開発を行っているのかを知ることができます。組織が大きくなるとどうしても隣の部門が何をやっているか見えなくなることがあるかと思いますが、そういったことを仕組みとして解消できる良い手法ではないでしょうか。

今後は、技術的な部分のレビューの力を高めることで、よりソースコードレビューを通じて品質向上に貢献していくつもりです。ひいては、ボランティアベースで回っているソースコードレビューの仕組みを維持できるよう、活動できればと考えています。

感想

PHP BLTに初めて参加(※1)したのですが、とてもカジュアルに発表できる場で大変楽しく過ごすことができました。人も多すぎず、懇親会の時間にはゆっくりとお話しする機会にも恵まれました。

規模の大小関わりなく、勉強会やカンファレンスで発表することは、今まで自分がやってきた事柄にけじめをつける、言い換えれば整理する機会として利用しています。整理を行うと、何を自分が理解しているかを理解することができ、大変有益です。また、そのような知見が他の誰かに役立つ知見になることも少なからずあります。

時間を見つけて、気軽に参加できるイベントでまた発表しようと思っております。

運営をしていただいている皆様、そして会場を提供いただいたGMOペパボ様、どうもありがとうございました!

※1: 本来であれば勤務先でやっていた時期に出ればよかったのですが、その時は入社したばかりで今やることに必死で回ってませんでした、すいません…。

qpstudy 2016.04 でITインフラ監視の今後について発表しました #qpstudy

昨日は、qpstudyというITインフラの話題を中心に取り上げる勉強会で、ITインフラ監視の今後について発表してきました。

発表内容について

「ITインフラ監視の今後を考える」と題して、発表しました。

今回は「こうだからこうだよね」という感じではなく、この後に密かに予定されていたグループディスカッションのための種まきをするべく、会場の皆さんと課題を共有する目的でお話ししました。ですので、結論があまりないふわっとした発表のように聞こえた方もいたかもしれません。

会場の中でいろいろお話を聞いていくと、課題に掲げた内容で、いろいろ悩んでいる方が多いのだなという印象を受けました。例えば、今の業務に追われてしまっているのかなと感じる方もいらっしゃいました。

後のグループディスカッションを聞いていると、グループの方々が意図されたかどうかはわかりませんが、投げかけたテーマが織り込まれた状態で議論が繰り広げられていました。今回、一定の役割は果たせたかなと考えています。

グループディスカッション

今回のqpstudyは、Outputしていこうという目的のもとに、グループディスカッションが行われました。人数が多い勉強会というと、どうしても受け身になってしまうところがあります。そこを、どんなことであれOutputすることで、今日のことを一人一人が自分の価値に転換してもらえたら、という運営の皆さんの想いがあってのものだったようです。

私がいたグループ11は、「体系化」をテーマに話をまとめました。「レガシー(ここでは特に負の遺産)」と「経験」は背中合わせの関係であるけども、そこから抽出される物事がモデリング・構造化されることによって監視の知見が明文化・共有できるものに転化できる。その転化の方法として、学術論文や学会の研究会発表といったアカデミックな手法が参考にすることで、業界全体に知見を共有できるのではと考えられるのではというものでした。また、最近の若い人は修士号またはそれ以上を持っていることも少なくなく、そういった若い人に知見の体系化を担ってもらえればいいのではという意見を提案しました。

IMG_3317

各グループの発表は、チームによって、焦点を当てている事柄が違っていて大変興味深いものでした。例えば、監視のしかたをどうするか、実際に業務で困っていることの共有、自動化をどのように推進するかなど、様々なものがありました。私が印象に残ったのは、「重要な監視項目とは何か、それは誰にとって重要なのか。」を議論していたグループでした。技術者だけですとどうしても技術者に偏った意見になりがちだけれど、ステークホルダーとなっている別の業務担当にとって重要なことが見落とされていることがあるのではないか、というものでした。私は、レポートラインを洗い出すことで、誰にとって重要なのかの「誰」の部分を適切に洗い出せるのではないか、その上で「誰」にとって良いものかが考えついたり相談できるのではと考えています。

感想

監視の設計や実装は、私が以前執筆した「ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)」である程度体系化したのでやり方のモデルは一定の結論が出ていると考えているのですが、実際の運用であったり、組織の中でどのように立ち居振舞うかについてはなかなか答えが出ない悩ましい問題だと改めて感じました。また、自社サービスで監視業務を行っている人は、孤独な人がまだまだいることも、以前同じ境遇にいたことを思い出して辛い気持ちになりました。

今回、グループディスカッションを通して、知見はもちろん、悩んでいるのは自分だけではないということが共有できたことで、少しでも孤独感を軽減できる機会になれば良いなと思いました。そうすることで、今の問題を解決するモティベーションが上がればいいなと応援したくなります。

あと、監視の業務をはじめITインフラの業務を減点法で評価されてしまう悩みもあるなという話がありました。これは、加点で評価される仕組みを自分たちで積極的に考えて提案し、導入してもらうことで解決できないかと考えています。例えば、パフォーマンスを向上させてより多くの負荷に耐えられるようにしたり、運用コストを軽減して同じ人数で支えられる業務量を増やす、などです。または、GoogleのSREではありませんが(See also: Error Budgets and Risks | USENIX, Google – Site Reliability Engineering)、Error Budgetという考え方を導入して、挑戦の中で発生する一定の問題発生は許容してもらうような仕組みがあってもいいかもしれません。

いずれにしても、監視業務は多くの組織でまだまだ改善できる余地があって、そのための知見をどんどん共有・活かす場を作っていくことが今後のITインフラエンジニアの幸せにつながるのではないかと、考えているところです。

運営の皆様、大変お世話になりました。どうもありがとうございました!