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が外部の方に勉強会用として初めて開放したイベントになりました。

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

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

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インフラエンジニアの幸せにつながるのではないかと、考えているところです。

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

2015年を振り返る&退職のご報告

2015年を振り返るエントリです。毎年棚卸ししつつ書くことで、自分が何をやったかを思い出すものになっています。

対外的な活動

今年は大きく3つありました。

  1. 単著の出版
  2. YAPC::Asia Tokyo 2015でのトーク
  3. 都立産業技術高専での非常勤講師

1は、初の単著を出版する運びとなりました。「「ITインフラ監視実践入門」という本を書きました!」というエントリで詳細を書きました。こうして出せることでなんとかほっとしています。

2は、2年連続でYAPCでトークをすることができました。今年は倍率が高くてできるか心配だったのですが、ご縁があり採択していただくことができました。詳細は「YAPC::Asia Tokyo 2015で開発・運用業務改革に関する発表をしてきました&感想 #yapcasia #yapcasiaE」に書きました。

3は、2015年の後期から都立産業技術高等専門学校(高専)でプログラミングの科目を担当する非常勤講師をしています。これは情報教育関係でご縁があり、仕事を紹介してもらった次第です。ソフトウェア開発をするのではなく指導するという毛色の違った仕事ですが、明日の仲間を増やすきっかけになればと思いながら取り組んでいる次第です。

個人ブログ

はてなブックマーク数の表示が2つあるものがありますが、これは2015年10月からこのブログをHTTP/2に対応した際に発生したURIスキームの変更によるものです。前者がhttp、後者がhttpsでアクセスした時のブックマーク数となります。1つしかないものは、パッと見で分かりにくくてすいません、9月まではhttp、10月以降はhttpsと思っていただければ幸いです。

子供が生まれまして、昨年に比べて勉強会へ行けるタイミングがぐっと減ったため技術エントリも減っております。これは、状況が変わって力をを注ぐところを変えているんだな、と思っていただけたら嬉しいです。

状況が変わったことに関連して、「エンジニアとしての落としどころを作る」というエントリを書いたのですが、これが370ブックマークを超えていて、結構伸びたなという感想を持っています。生き方に悩んでいる方が一定数いるのでしょうね。私もその一人です。

会社のブログ

勤務先でもブログ「インフラエンジニアway – Powered by HEARTBEATS」を共同執筆者の一人として書いていました。以下は私が担当したものです。

今年は1月に書いたRundeckのエントリがよく読まれていたようです。ジョブスケジューラの選定は運用時の頭を悩ませる問題の一つであり、かつベストプラクティスがなかなか見つからないところにフィットしたのではと分析しています。

また、運用とは関係ありませんが、Golangに関する記事も読まれているようでして、Golang熱が高まっているのかなと感じる結果となりました。

退職のご報告

先のブログでもおなじみでした、本務として勤務していた株式会社ハートビーツを今年いっぱいで退職することとなりました。謹んで報告いたします。

これからはITインフラが盛り上がるぜ!と思って入社したものの、はじめの頃は肝心のITインフラの運用で大きくつまづいてしまい、多くの人に大変な迷惑をかけてしまいました。そんな中、残されたソフトウェア開発の力を使って、ITインフラを直接扱うエンジニアの仲間の土台を支えるソフトウェアを開発し、自動化・標準化を推進する立場となりました。その中で、初期の失敗を挽回したいという一心で、なんとか今年のYAPCでご報告するレベルにまで到達させることができました。

これも、粘り強い、そして優しい仲間に支えられた結果だと感謝しています。本当にお世話になりました。ありがとうございました。

まとめ

今年は1人目の子供も生まれ、ガラッと生活が変わりました。そのため、独身時代のように仕事中心ではなく、できるだけ多くの時間を家庭の時間として使うよう生活するように変わりました。それでも、思ったより自分は対外的な活動をしているなと感じました。

今ある人生は過去からの連続した変化からの結果で、それが未来に続くという認識は、昨年からは変わりません。しかし、人の生死に限って言うと、連続性がない大きな変化だと受け止めています。正直、どのようにやっていけば良いのか結構悩んだ年になりました。それでも、こうやって生きていけているので、なんとかなっているのかもしれません。

来年は本務の勤務先も変わりますので、また違った変化が起こることでしょう。いろいろなことがありそうですが、まずは淡々と受け止めて、冷静な判断と燃え続ける心をもって事に当たる所存です。

皆様、今年も一年、大変お世話になりました。良いお年をお迎えください。

「ITインフラ監視実践入門」という本を書きました!

このたび、「ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus)」という本を執筆・刊行する運びとなりました。

2016/01/16より発売です!Amazonなどのオンライン書店では先行予約も始まっております。

ITインフラ監視実践入門 書影

電子書籍版もあります。「Gihyo Digital Publishing」のサイト、またはKindleをどうぞ。

こんな人にオススメ!

  1. サーバの監視設定ってどうやればいいかわからない
  2. サーバの監視設定はやったけど監視の業務をどう回せばいいかわからない
  3. サーバの監視についてまとまった情報が欲しい

本書では、体系的な知識を持ってすれば、多くの方にもサーバの監視設定を行っていただくことができるよう、まとめています。

現在、Webサービスをはじめとしたサーバを用いたシステムを運用するにあたって、サーバの監視は外せない業務となっています。しかし、サーバの構築やチューニングの情報に比べて、サーバの監視の設定や業務についての情報はあまり多くなく、苦労されている方も多いかと思います。また、サーバの監視は経験と勘を持つ人が強いということも、難しいという意識を高める要因になっているはずです。

本書が、そんな悩みを解決できる一助になれば、幸いです。

章構成

大まかな構成は、概要(1, 2章)→設計(3〜6章)→構築(7章)→運用(8, 9章)となっています。

1章は、監視の必要性についてお伝えしています。

2章は、この後の章で述べる監視設計についての流れについて説明します。システムを「5つのレイヤー」に分けて整理していくことで、何をどのように監視するのか整理しやすくする手法を紹介しています。

3章では、これから監視するシステムの現状分析方法について述べています。どのような情報が設計時に必要になるのか、網羅しました。

4章では、監視の設計で最も重要な監視閾値の定義の仕方についてお話ししします。3章の情報をもとに進めていきます。

5章では、監視サーバの設置についてまとめています。オンプレミス、SaaS、それぞれの利点と注意点に留意しながらどのように監視サーバを設置すると良いのかをまとめています。

6章では、監視業務をいかに回すかを説明します。障害発生時の意思決定の流れ、そして休日・夜間にどのように監視を継続していけば良いのかを確認します。

7章では、MackerelとUptime Robotを用いて監視システムを構築する方法をご紹介します。実際に手を動かして監視設定を行ってみてください。

8章では、障害対応をはじめとした日々の運用の回し方について述べています。障害をいかに迅速かつ丁寧に対応するのかのノウハウをお伝えします。

9章では、自動化を見据えた監視システムの設計のコツについてお話しします。

執筆のきっかけ

以前、YAPC::Asia 2014でサーバ監視設定に関するトーク(「YAPC::Asia 2014 に参加してトークして飲み切ったら夏が終わった #yapcasia」を参照)をしたことがありました。その場では、会場を埋め尽くすほどの多くの方に関心を寄せていただきました。

そこで、トークではお話ししきれなかったことを本として改めて網羅し直すことで、より深く、そしてより多くの方にサーバの監視設定についての知見をお伝えできたらと思い、執筆することになりました。

ぜひお買い求めください!

そして、感想をブログに書いていただいて、Twitterなどでシェアしていただけたら嬉しいです!確認し次第、読むようにします。

次世代Webカンファレンスに足を運びました #nextwebconf

本日は、次世代Webカンファレンスというイベントに足を運んできました。世の中にはいろいろな勉強会がありますが、こちらは識者たるエンジニアの皆さんが時事放談をするちょっと変わったイベントとなっています。

その道の前線にいらっしゃるからこそ日々考えていらっしゃる事柄について、深くじっくりと伺える良い機会となりました。

運営の皆様、そしてパネリストの皆様、どうもありがとうございました!

今回も、例によって感想とメモを残します。

※ビデオもYouTubeの「nextwebconf」チャンネルへアップされるそうなので、セッションの内容に興味がある方はご覧になってみてはいかがでしょうか。

まとめと感想

server_perf

サーバパフォーマンスを引き出す話題に絞り込んだ、話す皆さんは結構大変だろうなと感じながら聴いたセッションでした。Webアプリケーションとしてサーバサイドのソフトウェア開発を行う比率は減り、代わりにAPIサーバの開発の比率が上がってきているというお話でした。その中で、スループットよりもレイテンシ、大きなリクエストより小さなリクエストが増えるシフトも発生しているとのことでした。その中で、並列処理に長けた言語を駆使することが一つのキーポイントになるようでした。

僕も最近は業務ではGo、個人ではScalaに触れる機会があるのですが、これらはどちらも並列処理に長けた言語であります。勘所としていかに活用すると良いのか、自分の理論を形成するための非常に良いヒントをいただけた時間になりました。

server_arch

これからのサーバサイトのアーキテクチャについてのセッションでした。Mincroservices の話はもちろん、CD(Continuous Delivery)、そしてgRPC Gateway開発者の @yugui さんがいることもあり gRPC の話が随所に登場しました。

気になったのは、Googleなどのハイパージャイアントと同じ設計思想を、そのまま中小のWebサービスやスタートアップに採用していいのか、ということでした。ある程度枯れて、実績があり、かつビジネスの速度が向上できるなら積極的に取り入れるのは賛成です。一方で、最高のアーキテクチャを採用しようとしてオーバーエンジニアリングになり、商売として成立しなくなったら元も子もありません。そのバランス感について議論があったらよかったなと思いました。

security

Webのセキュリティ、特にブラウザと、ブラウザを絡めたアプリケーションのセキュリティの議論が繰り広げられたセッションでした。Webアプリケーションそのもののセキュリティは、徳丸本をはじめとした知識を備えているエンジニアが取り組めばほぼ問題ない状態であることはセキュリティ業界の人としては「仕事はどうしよう」ということらしいです。

興味深かったのは、W3Cをはじめとした標準化を進めている団体の仕様はセキュリティ部分について網羅性が足らないという話でした。理想は仕様策定段階で潰せるといいでしょうが、実際は実装から潰していくのが良いという着地点は、非常に現実的だなと感心したのでした。セキュリティを専門とするエンジニアの方たちは、地続きにつながる未来に向かって戦っているのかもしれません。

http2

今ホットなHTTP/2の話題です。HTTP/2が必ずしも高速化を実現しないという現実の把握から、それを改善するためのプライオリティ付けの見通し、そしてTLS 1.3やQUICなどの新しい技術に対しての話題に広がっていきました。

プロトコルはプログラミング技術ほどは変化は激しくないにしても、その基礎となる技術の変化が徐々に早まっていることは、少々恐れていることでもあります。これは、ソフトウェア開発の基礎知識の刷新速度が早まることを意味するからです。これは、少なくとも僕に対する技術者の勉強の仕方に変化を促されているのかなと考えているところです。

monitoring

現場で普段関わっている、サーバの監視について意見が交わされたセッションでした。これまでの監視を棚卸しし、これからの監視がどうあると良いのかに話がつながりました。これからは、より細かいデータの分解能、障害予測、そして自動復旧がキーワードになりそうです。また、新しいWebサービス提供企業ほどDIYで監視システムを構築するのではなく、SaaSを利用した監視システムを利用している傾向があることも興味深いことでした。

僕はMSPの未来をどうするか具体的に手を動かして進めていく立場にあるので、大変興味深く議論を聞いていました。これは僕個人の意見ですが、新しいWebサービス提供企業がSaaSを使って監視するのは大変合理的だと考えています。それは3つ理由があり、開発によりコストをかけられる、ITインフラエンジニアにかける給与よりもSaaSのほうがおそらく安い、そして現時点では競争が激しいのでより良い機能がどんどんつく可能性が高いからです。だからこそ、MSPにおいて監視の部分でどう価値を出していくのか、どんどん回答を出さないと市場に置いて行かれてしまうのではないかという危機感を持っています。

メモ (敬称略)

server_perf

  • モデレータ
    • @mirakui
  • パネリスト
    • @xcir
    • @cubicdaiya
  • サーバサイド技術は随分細分化されている、だからこそパフォーマンスだけに絞る。
  • ISUCON
    • 仕事でやっていること以上はできないんだなってのを痛感する @cubicdaiya さんのISUCON後日談
      • アクセス分析
      • 業務分担
  • Webの比率の低下
    • パフォーマンスチューニングの勘所の変化
    • APIリクエストの増加
    • サーバ負荷の低下
    • いかに、リクエスト数自体を低下させて負荷を低減させるかがポイントになりつつある。
    • 某ECでは
      • Webは1割、他は全てスマホからのAPI。APIはほぼJSON。
      • やることは減ったが、単体の性能がより求められるようになった。
      • レスポンスデータ量は減ったが、レイテンシがより求められる。
  • 改善の取り組み
    • 全てには流れがある
    • 3〜4万接続/台のnginxサーバを安定してどう動かすか
    • Proxyサーバを書いてAPIサーバに負担をかけない
    • キャッシュの非同期化、検索リクエストの非同期化→ジョブワーカーベースで実行。
    • トランザクション処理が必要となるものはチューニングは難しいので、札束でひっぱたく。
      • IODrive, など。
    • そもそも仕様を変える
  • キャッシュ
    • 銀の弾丸
    • 運用のしやすさとはトレードオフとなる
    • 基本
      • 生成コスト
      • パフォーマンスがどのくらい上がるか
      • どのレイヤーに置くか
      • 範囲 (共通のものから優先する)
    • 消すとき、消せないとき、どうするのか。
    • ログインしているユーザ情報はキャッシュしない→事故の防止、A/B回線がしづらくなるのを防ぐ。
  • 言語の選択
    • 言語はあったものがあればいいのだ。
    • 流行っているからだけでは理由が浅い、特性を見極める。
      • 支えるスタッフが多いから
      • アプリにあっているから
    • CPUの1コアあたりの性能はすでに頭打ち マルチコアで性能を引き出す
      • 並列・並行処理
      • マルチコアで扱いやすい言語を選択する (GoとかScalaとか)
      • LLだとfork()しないといけないので計算機コストがかかりやすい
      • Railsは1リクエストあたりのオーバーヘッドが大きいので高リクエスト時代には見合わないかも
  • フレームワーク
    • ルーティングできればよい、軽量なフレームワークを選択する。
  • ミドルウェア
    • Varnish
      • 4.1 いじれるところが増えた
        • bodyの加工が可能になった
        • 画像の圧縮なども可能(いわゆるスモールライト)
        • 黒魔術からインタフェースへ
      • Peakでキャッシュヒットレートは95% 現在は85%くらい
      • 多段をしないとキャッシュ不整合が起きやすい
      • 将来: HTTP/2: 4.x系で対応の準備は進んでいる
      • 最近は落としたことはない (3系の古いものはあったが最近はない)
    • nginx
      • APサーバ 30〜40台 その前に置いている
      • 検索サーバの前段にもある
      • Push通知のサーバ
      • Deploy
      • Lua, mrubyなどで拡張していく 簡単な処理を行うAPサーバを書いて高速に裁く
      • nginx script
        • 変数のset, contentフェーズへの書き込み, ヘッダの書き換えがややできる程度
      • 全ての処理をノンブロッキングで処理しないとnginxの良さが失われる
  • ネットワーク
    • 米国は国土自体の大きさが違う!
      • TLSの最適化のためのコード(セッションキャッシュ)を入れ込んでハンドシェイクのコストを抑えている
    • 最初から海外のときは
      • 便利にAWSさんお願いします!
        • US-EAST(世界中だいたい同じくらいの速度で…遅い!日本よりはまし)
        • us-east–1は障害が多いという話もあるので考える
      • 近いところにサーバを上げてしまう。
    • CDN重要
    • 日本ってネットワークトラブルが少ないですよね…
      • 大雨で
      • 海底ケーブルが切れる
    • 東南アジアで6MBを超えたアプリはDLされない
      • Opera Term/Opera Miniを使うと画像サイズを小さくしてくれるとかJSをサーバサイドでレンダリングしてくれたりとか
      • 東南アジアはOpera Mini対応で苦しんでいるらしい ガラケー時代のように
  • 未来の話・まとめ
    • CDNを使わざるをえない時代に
      • 日本: オフロード
      • 海外: レイテンシ改善(ユーザの近い場所に)
      • 昔に比べて求められることが増えた
    • アプリを載せるレイヤーが上に上がってきている
      • フロント側にボトルネックがシフトしている

server_arch

  • モデレータ
    • @ryushi
  • パネリスト
    • @yugui
    • @making
  • gRPC Gateway
    • Protocol bufferでとりまとめて返す
    • HTTP/2時代に沿ったものに
    • よくない点: JSONベースのAPI(今まで)と互換性がない
    • サーバプッシュが支えてP2Pもできて良い
  • SOAPとgRPC
    • 堅いところだと今でもSOAPは主流
  • back pressure
    • いらないのでは?
    • あってもTCPの接続断の復帰などを考えると処理が難しいのでは
  • Reactive Programming
    • 昔からあったけど、人類が扱えなかった。と思う。
    • スケールさせるためには必要だ。
    • ハードとお金の問題だけでは解決できなくなった。だから、ソフトをちゃんとしないといけない。
    • Reactive Streams
    • Elixr は「隣の芝が青い」くらいにしか見えないw
  • ネットワークに困っているのならGCPに移ればいいじゃない。
    • スイッチの話はあるけど、まあこれは内部の話だ。
    • 外との通信も解決するのか、な?
  • ScalaとGo
    • ScalaはTwitterの後をついていけばなんとかなるという安心感
    • ビルド速度は遅いが(確かに遅い)
    • Golangの依存ライブラリのvendoringが辛い(でも1.5から解決していく気がするで)
    • ライブラリを一カ所にまとめて、社内標準にするやりかたもどうか。
      • バージョン齟齬の阻止
      • 検証の一本化
  • どんな道具が揃ったら乗り換えるのか
  • Microservicesのコンテキスト
    • 狭義のMicroservicesとは?
      • サービスレジストリ・サーキットブレーカ
      • Netflixの事例
    • デプロイな簡単なインフラが必要
      • プログラミング言語に縛られない
      • Dockerで標準化
        • メタデータ付与の必要性は検討されるべし
    • モニタリングが簡単なインフラが必要
  • 「地雷を踏む」
  • Monitoring
    • サーキットブレーカ
    • Prometheus (dockerコンテナのモニタリングツール)よくできてる

security

  • モデレータ
    • @hasegawayosuke
  • パネリスト
    • @kinugawamasato
    • nishimunea
  • 「徳丸先生に怒られないセキュリティ」
  • Webのセキュリティはサーバ側の対策に比重が高い
    • やり方に型が出来ていて銀の弾丸はある
    • 改めて研究調査しなくていいよね
  • 「新しいXSS」
    • 遊び甲斐がある!!!
    • Deep Link
      • 今までの延長で考えられていなくて準備できないパラメータでアプリが呼ばれたときの対策がまだまだ
      • calurator:とか
      • Firefox 44が出たときに明るみになる脆弱性とか
  • ブラウザの特殊な機能を使った脆弱性・ブラウザそのものの脆弱性
    • Webのセキュリティは曖昧なところで決まっている
      • Cookieもhttps, httpで共有
      • Refererとかどうよ https→httpとか丸見えだし
    • 自分の中で整理したい(nishimuneaさん)
    • IETF, W3Cの情報は網羅性はない
      • http://www.w3.org/TR/css-font-loading–3/ とか (originって言葉がない)
    • HSTS Super cookiesの記載は、大元のドキュメントだけ見ていても脆弱性はわからない。
    • 仕様面での脆弱性調査はあまり多くの人が見ないのでブルーオーシャン!
      • 仕様の策定段階で入るのはどうすればいい変わらない
      • 実装を基にした脆弱性報告の方がやりやすい
      • お金になるのは脆弱性報告…
  • 今のWebでそれはアリか?
    • 新しいものを入れるbut脆弱性報告の検証はあまりないっぽい→ダメだったら停止
    • 薬とか、重篤な副作用が起こらないように検証とかありますよね?
    • 新しいものをリリースしたときに、少なくとも脆弱性がある状態にさらされるけど本当にいいの?
    • 規格を考えている中の人、それでいいの?
  • Cookie
    • Origin Cookie, Secure Cookie
  • 新機能
  • CDN
    • 「信用するしかない」
    • SRI https://www.srihash.org/
  • file:// スキームの問題
    • 他のすべてのオリジンのスキームにアクセス可能
    • 権限がめっちゃ強い
    • Electronが積極的に使うので問題が起こるのではないか
  • できる技術者は自力で脆弱性は撲滅できている。その上で、セキュリティ診断の人たちは何をしてくれるの?どうやって今後生きていくの?
    • 一方でできない人はまだまだいるので、そこに入り込む余地はある。
    • そこって、セキュリティよりも開発者としての育成を徹底したほうがいいのではないか?
  • Click Jacking

http2

  • モデレータ
    • @jxck
  • パネリスト
    • @tatsuhiro_t
    • @jovi0608
    • @kazuho
  • HTTP/2の今
    • RFC7540, 7541で仕様化が完了
    • でかい揺れ戻しやでかい脆弱性も特になく無事仕上がった
    • 主要ブラウザはサポート完了
    • サーバ側もnginx, h2o, nghttp2(ライブラリ)が揃っている
    • 言語側もサポートを進めるべく取り組まれている
    • h20、http/1系よりも速くなっていない部分も…まだあるので頑張りたい
  • 速くなることとの関係
    • 「速くなる」: ダウンロードのパイプラインの制限がかからない
    • 「遅くなる」: 依存関係の解決が全て終わるまで画面のレンダリングは終わらない 以前ならHTML, CSS, JSがダウンロードできた段階で終わってた
      • parse paintは昔のほうが速い
    • 1本の接続がブロッキングされると破壊的に遅くなる
  • プライオリティ
    • mime type を見て、CSSやJSを優先的に送る(h2o)。
    • ブラウザ側は現在進捗中。ChromeはIssueがある。Safariもがんばるっぽい。Firefoxは進んでいる。
    • ただ、プライオリティをつけたからといって万能的によくなるわけではない。
  • RTT
    • 効果が出るサイト・出ないサイト
    • 1RTTで差が出る
  • P2P Extension
  • サーバとクライアントの負荷が下がる
    • 1コネクションで一括で転送できるので互いに負担が少ない
    • TLSの接続でもさらにアドバンテージがある 暗号化による負担よりもリクエスト数提言による負荷低減のほうがアドバンテージがある
  • ではGoogleなどの巨大組織のみしかメリットがないのでは?身の丈にあうの?
    • 1%の売り上げ向上
    • ハイパージャイアントと同じ土俵に上る
    • シャーディング・インライニングが入らなくなる
  • いつからHTTP/2対応サイトを作るべきか
    • モバイルだともうすぐ(ブラウザのサポートは終わっている)
  • HTTP/3はどうなのか?
    • TLS 1.3に今は目が向いている、その上で次。
      • TLS 1.3はメジャーバージョンアップと呼んで良いほどの改良が入る。
    • QUIC
  • WebSocket
    • HTTP/2では動きません!
    • 今後どうなるんだろう、見通しはわからない。
  • QUICって?
    • 0RTT
    • TCPのいいところをUDPに実装
    • Socket Buffer の問題も解消する
    • h2oも取り組むのは時間の問題
    • ゲームではUDPが普通だから期待も高い
  • テキストでコマンドを打てる時代から、バイナリプロトコルへ。
    • “Hyper Text”ってなんだったのか
    • 「みんなTelnetでデバッグしてるの?curlでいいじゃない。」
  • 負債はいつまで残るのか
    • 2020年にHTTP/1.1と5だけ、という世界もあり得る。
    • FTP生き残ってますよね?サーバは20世紀にたてたのが最後かもしれませんが。
  • 進化には意味がある
    • ブラウザ・サーバを実装する人が追いつき、使う人が追いつけるのかは悩ましい。
    • エコシステムの中心が移った時に1.1を使う人は取り残されているのでは、という恐怖がある。
    • 勉強するコストが上がっている。
      • HTMLをタグを教えるだけではもうどうしようもない時代
    • セマンティクスが残るのは、今はいいけど、今後負債になるのではないか?
    • 学習コストは…まあ、1年ごとに変わることはないからね!

monitoring

  • モデレータ
    • @songmu
  • パネリスト
    • @fujiwara
    • @mikeda
    • @rrreeeyyy
  • 監視とは?
    • 落ちたら困るものを見つける
    • リソースの傾向を見てあらかじめ手を打つ
    • 継続的なテスト (kazuhoさん)
    • インフラと開発の境界は薄くなってきている
  • 死活監視からメトリック監視へ
    • 分けることを重視する人とt、わけなくてもいいと思う人といるよね。
    • 「ベストエフォートはなんだったのか?」
  • 分解能
    • 5分→1分の時代へ
    • 1分の中の数秒間だけ劣化した時の問題をどう捉えるか
  • 監視難しすぎる問題
    • 言語別のくせ
    • ミドルウェア別のくせ→運用中にわかる
      • 新しいミドルウェアを増やさない
      • アプリエンジニアも関与してもらうとかどうかな
      • ただアプリエンジニアは反応してくれる人とそうでない人がいる
  • Chefのよさ
    • 秘伝のShellスクリプトが、プログラマでも触れられるような仕組みになって、プログラマでも関与できるようになった。
  • インフラだけで動くと、ノウハウが共有されづらい。
    • HBの「きりわけとエスカレーション」の話は吉川さんから出た。
    • 自社サービスでサービスに影響が出るアラートを感じてもらうには?
      • 対処のレベル感 4段階 3営業日・翌営業日・即時・緊急
  • 「人がいないけど24時間 それをなんとかしているのがWeb業界」
    • 当番を組めるほどの体制を組む必要がある。
    • 委託が難しい理由は、同じものを見て同じレベルでやるか。
      • トレードオフ
      • とはいえHBはソースは見てます(マネージドの場合)
    • 事故るのはアプリ要因が多い、半々…?
  • 新しい技術
    • TSDB
      • ZabbixのMySQLを馬力のあるマシンでとりあえずこなすってのはできる
      • 大きなサービスとしては必要となるよね(Mackerelとか)
        • InfluxDBはインタフェイスが不安定なのでやめた
        • DatadogはCassandraを採用しているらしい
        • ZabbixもCassandraを採用するとスケールする…らしいがそれすごい手間っぽい
    • 監視
      • 監視とクラスタマネジメントがセット、Consulを推したい。
      • ただしConsulのアラートを投げる方法は別に考えないといけない。
    • fluentd
      • ログ収集の革命
      • だんだんストリーム処理へ
  • 監視システムが徐々に複雑になりつつある→監視ソリューションのアウトソース
    • MSPでは業務として採用するのは、現段階では採用は行っていない。
    • 自社サービス: 今後はZabbixなどからシフトさせていきたい
    • 共通: 監視システムの監視をするのは辛い
    • 新しい会社は、外部の監視サービスにアウトソースしている傾向が強い模様。(「WEB系各社で使われている監視ツールまとめ – mikedaの日記」より)
  • 通知と障害対応の予測
    • 外れ値の認識をどうするか
    • 画像レベルで認識してズレを見る: ただ、一般化は難しい
    • 基本的な線形回帰を越えたものはまだ出てきていない
    • 死活監視の0/1の問題ではすでにない
    • デプロイなどのイベントの内容
      • イベントプロットができるようになると、そこだけ通知停止とかできそうでいい。
      • 「なんの」障害かを特定するのは難しい
  • マネージドサービスの難しさ
    • ミドルウェア自体を使うことは楽になった。
    • 監視が難しくなる 分解能・メトリックの種類はPaaS次第となる。
  • オートヒーリング
  • Microservices
    • コンポーネントが増えて複雑化すると解決が難しくなるのではないか
  • 新しいミドルができたら、監視の口も開けて欲しい。
    • h2oとか
    • JavaScriptの動的なページ(フロントエンド)の監視をどうするか
  • 新時代の監視
    • 通信の流れが続いているか…アプリケーションと連携した監視が求められる
  • アプリケーション、ミドルウェアを作る人も、だるいかもしれないけど、監視のためのパスを作ってもらえるといいな。より高度さが求められる監視に追従できる。