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

LINEで送る
Pocket

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

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

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

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

LINEで送る
Pocket

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

LINEで送る
Pocket

このたび、「ソフトウェアエンジニアのための 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などでシェアしていただけたら嬉しいです!確認し次第、読むようにします。

LINEで送る
Pocket

TENTO 第4回プレゼン大会の幹事をしてきました

LINEで送る
Pocket

少し遅くなりましたが、10月25日(日)、僕が小学生〜高校生にプログラミングを教えるボランティアをしているTENTOにて、毎年恒例のプレゼン大会の幹事をしてきました。今回は4回目、東海大学さんのキャンパスをお借りして催すことができました。

プレゼン大会について簡単に説明すると、TENTOは小学生〜高校生にプログラミングを指導する私塾でして、様々な年齢の生徒さんが自分のレベルにあわせて様々なソフトウェア開発を学びます。言語も様々、ペースも様々で、現代の寺子屋といっても過言ではありません。

当日の模様をブログにまとめている方がいらっしゃいましたのでまとめてみました。

また、以前のプレゼン大会の模様は次のエントリにまとめています。

IMG_3752

さて、今回のお話は、「発表に賞はつけない」「実際に作品に触れることの良さ」そして「イベントのネットワークについて」の3点についてお話しします。

発表に賞はつけない

今回、発表では3つの部門(「Viscuit+Scratch高学年」「Scratch低学年」「テキストプログラミング」)を用意しました。これまでは審査員の方がそれぞれの部門のトップ賞を決めていたのですが、今回は止めました。そのかわり、審査員はスーパーバイザーとして、発表後に発表者した子全員に対して30秒程度の講評をお話し頂くことにしました。

なぜこうしたかというと、3つの理由があります。

  1. 一人一人、年齢と成熟度が違うから。
  2. プログラミングの良さを決めることは簡単な話ではないから。
  3. 何を糧にして明日プログラミングに取り組めば良いかプロからのコメントを送って欲しいから。

1は、年齢が高くなればなるほど、人として知識や知恵がつく傾向にあります。従って、「小学1年生」とよほど細かく単位を区切らない限り、上級生の方が良い作品を作りやすい傾向が出てしまい、審査に公平感が出なくなります。また、細かく切ることができるほどには生徒は増えていません。

2は、例えば競技プログラミングなどの明確な基準があれば賞を出すことはやぶさかではありません。しかし、TENTOのプレゼン大会で出てくる作品は、テーマの縛りがない状態で、生徒さん一人一人が最も自信があり、最良だと考えて開発した作品が出てきます。従って、一定の基準を設けて審査することは容易ではありません。言い換えれば、一人一人が最高の作品を作ってきているのです。

3は、1と2を受けてのことでした。今、前線でソフトウェアと向き合っている人たちからの温かい言葉を受けて、生徒さん一人一人の自信につなげて欲しいと願い選択しました。担当は、OtOMO 代表の倉本さん、株式会社ワディット代表で @yusukebe こと和田さん、そしてピープルウェア翻訳者で東海大学の山浦先生にお願いしました。

イベントと言うとついつい賞を出すと自然と考えてしまいがちですが、そうではない形があるということを、日本のプログラミング教育のパイオニアを自負しているTENTOから発信できたとしたら、幸いです。

実際に作品に触れることの良さ

今回、発表は1トラックだったため、急増する生徒さん全てを発表のステージに立ってもらうことは叶わない状況となってしまいました。そこで、発表する人も、そうでない人も、作品を展示できる機会を設けました。これは昨年試行して好評だったため、今回からイベントの中に正式に組み込むことにしました。

IMG_3788

TENTO代表の竹林さんは「プレゼン大会を学園祭のようにしたい」という想いがありました。また、全ての発表したい生徒さんに何らかの機会を提供することは、指導を担当する私たちの責任でもあると考えていました。その結果として、展示が存在しています。

展示の良い所は、生徒さん同士で交流が発生することです。これは情報交換を通じて互いのプログラミングスキル向上が期待できることはもちろん、「これは良い作品を作っているな!」と互いが喚起しあうことでモティベーションを高める効果もあります。また、あちこちに人が行き交うため、まさに学園祭のような様相を呈します。なかなかよいものですよ。

この展示イベントだけでももう少し短期間でやってもいいかな、そう思えるくらいです。

イベントのネットワークについて

せっかくですので、ネットワーク環境について述べておきます。

ネットワークは、公衆回線はUQ WiMAXのURoad-Home2+ → ルーターはYAMAHA RTX810 → Wi-FiはYAMAHA WLX302 で組んでいます。PCは40台以上接続しています。この状態で、ノントラブルで乗り切ることができました。

ScratchやViscuitはhttpの非同期通信が多発しますので、ルーターにNATテーブルを多量に要求するなかなかシビアな環境です。また、家庭用Wi-Fi機器ではさすがにこのPCの台数を支えることはできません。一方で、アクセスポイントを増やすだけですとかえって通信が輻輳しますので、よほど慣れていない限り避けた方が良いです。

これらのコツは、Software Design 2015年3月号の「カンファレンスネットワークの作り方」で解説されていますので、検討される方や、実際にネットワーク環境に困っている方はぜひ参考にしてみてください。

一つのフォーマットの完成

TENTOのプレゼン大会を第1回から手伝ってきまして、4回まで来ますとだいたいのイベントのフォーマットができたかなと思っております。発表と展示、相互に盛り上げることで生徒さんのプログラミングスキル向上の一つのマイルストーンにできているのではと自負しています。また、TENTOという場で、コンピュータとは何か、そしてそれを通じて仲間の絆や、学校で学びづらいスキル(プレゼンテーションや論理的思考力)を生徒さんが理解してもらえたら何よりです。

実は、私は家庭の事情から、このイベントを持ってTENTOを離れることとなりました。その一区切りに、TENTOで一番はじめに取り組んだプレゼン大会で締めることができることを幸運に思います。大変感謝します。

また、ここまでに至るまでに、代表の竹林さんをはじめ、多くの仲間に支えられてここまでできたことを深く感謝しています。重ねて、どうもありがとうございます。

IMG_3819

情報教育自体には引き続き関心を持ちながら生活して行きますので、イベント等でお会いする機会がありましたら、どうぞよろしくお願いします。

LINEで送る
Pocket

それでも僕は86のMT車を運転したい!

LINEで送る
Pocket

11月3日といえば文化の日で祭日。健康で文化的な生活を送るべく、我が家も相方の大型バイク(YAMAHA Fazer 8)と、レンタカーのTOYOTA 86 MT仕様の2台でツーリングをしようという話になりました。

IMG_3901

しかし、残念なことに86のクラッチが滑ってしまって走行不能に、ツーリングがあえなく中断となってしまったというお話です。

前々から構想はあった

この構想は実は前からありました。もともとは子供が生まれる前に相方のFazer 8でタンデムで行こうという話もあったのですが、相方が人を乗せるのが怖いという話になりました。では、僕がMTを運転して、それとともにツーリングならどうだという話をしたら、それならいいだろうということになりました。

以前「TOYOTA 86 を借りて伊豆へドライブに行ってきた」というエントリでも書きましたが、トヨタレンタカーでは店舗限定ですが86のMT車の貸し出しがあります。タイミングが合いそうな時に電話をして聞いてみるのですが、たいていタイミングが悪く空車がありません。しかし、今回は1日前に昼休みを使って電話をしたら「空きあります!」と聞いて「よっしゃ!」となったのでした。

相方には事後報告となりましたが、相方もツーリングには乗り気だったのであっさりOK。不思議な家庭ですね。

あれ、クラッチミートがなんか変だ…

さて、当日になりまして、いつもの近所のトヨタレンタカーでははなく、電車で15分のところにある錦糸町店へ。車は予定通り用意されていて、さて乗り込んでおチビを乗せに一旦家に戻ろうとすると…ちょっとクラッチが滑る感覚がありました。ミートするポイントがボヤーンとしているのです。この手の車はもっとはっきり厳し目のクラッチミートをするものなのですが、そうはならない。ただ、レンタカーでいろいろな人が乗っているから少し甘くなるのは仕方ないのかもな、程度にしか思ってはいませんでした。

そして、自宅で相方と合流して、目的地である館山の野島崎へ出発!

ただ、京葉道路〜館山道に入った後も異変が続くのです。5→6速にあげたのに、エンジンの回転が下がらないのです。6速なのに100km/hで3,000rpmほど回ります。ただ、トルクをかけずにしばらく走ると2,000rpm台に落ち着くので、僕の走り方に問題があるのかなと考えていたのでした(そんなことはなかったのだけれど)。

IMG_3885

この日はとにかく天気が良くて、天気のおかげで良い方向に転べばいいな、そんな期待さえ持っていたのでした。

ボンネットから煙が…

そうしているうちに、いくつかのパーキングエリアで休憩を重ねながら、館山市に突入。ここで異変が確信に変わります。館山バイパスでJR線路を越える陸橋で、4速 5,000rpm以上回さないと坂を登らないのです。あー、これはMT車のクラッチが滑って立ち往生をした人から聞いたダメなパターンだと理解しました。

あー頼むから止まんないでくれと思ってなんとか登りきった後、赤信号で止まったところでボンネットから煙がもくもくと上がってくるではありませんか!発進もままならず、このまま火でも出たらえらいことになるのでおチビを下ろして歩道に退避。後ろをついてきた相方もオートバイを安全なところに避けて退避。僕らのツーリングはここであえなく中止となってしまったのでした。

IMG_2986

その後、トヨタレンタカーのレスキュー担当者に電話でレッカー車を呼び、警察の方にも交通整理のために来ていただきました。右折車が少ない右折レーンがある場所で止まったので、交通渋滞にはならずに済んで少しホッとしました。警察の方には「86は軽いですから簡単に押せますよ!」と言われてバイパスから車を押したのは良い経験でした。みなさん、教習所で習うことは無駄にはなりませんからね!!やり方はお忘れなく。

DSC_0441

押し終わって退避が終わると、たちまちレッカー車も来ました。ドナドナされていく86を見ながら、遠足中に雨に降られて中断になった小学生のような気持ちで、家族一同悲しい思いに浸るのでありました。

IMG_2989

ドナドナの後

幸い、館山のトヨタレンタカーの店舗が近くにあったため、代車もすぐに手配することができました(※1)。代車は借りた時にいつも運転しているHV1グレードのアクア。あと、レッカー車の運転手さんに美味しい食べ物が食べられる店があると聞いてそちらに出向いて遅い昼飯を食べたのでした。

IMG_3907

アクアは良くできた車なのですが、今日は86のMTが運転したかったです。

車を返す時に、淡々と状況を説明しつつ、クラッチの点検はもっと密にお願いしたい旨を伝えました。MTに不慣れな人も運転しそうですしね。先方は何度もお詫びをされていましたが、誠意を持って対応いただいたのでこの点であまり言うことはありません。

トラブルもまた旅のうち

トラブルもまた旅のうちというと、寛容になれるのはまた不思議なものです。とはいえ、目的地に到達できなかったのは一家共々ちょっと心残りです。また、MT車を堪能できなかったのは僕としては大変心残りです。僕はこれに懲りずに、また時期を見て86のMT車を借りてツーリングに行くことでしょう。あの、MT車を運転している時の支配感は、AT車には無い感動があるからです。

ちなみに、乗り心地はATと変わりありません。興味がある方は「TOYOTA 86 を借りて伊豆へドライブに行ってきた」のエントリをご覧ください。

参考: Facebook – Yuichiro Saito – きょうは86のMTを借りられたので、館山まで走りに行っています。 (友達のみ)

IMG_3889

※1: トヨタレンタカーの貸渡約款には、第24条に故障時は指示に従うこと、第27条 第3項に故障等が貸渡前に存した瑕疵による場合は代車が出るとあります。クラッチ滑りは過去からの蓄積で起こっているので、第27条 第3項を持って交渉ができます。

LINEで送る
Pocket

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

LINEで送る
Pocket

本日は、次世代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の動的なページ(フロントエンド)の監視をどうするか
  • 新時代の監視
    • 通信の流れが続いているか…アプリケーションと連携した監視が求められる
  • アプリケーション、ミドルウェアを作る人も、だるいかもしれないけど、監視のためのパスを作ってもらえるといいな。より高度さが求められる監視に追従できる。
LINEで送る
Pocket