家族やプライベートを犠牲にして仕事や実績を得ていたことから目を背けられなくなった件
新型コロナウィルスの影響によって、急激に働き方が変わってきた。コロナ禍の初期、大体1年目においては、まだタイトルのような「家族やプライベートを犠牲にして仕事や実績を得ていた」ことから目をそむけることができていたし、なんとなくモヤモヤしていたけれど、そのような考えにある種至っていないような感覚であった。 コロナ禍の初期は、働き方が一気にオフラインからオンラインになって、出張や勤務など多くの時間的な制約から解き放たれ、随分と様々なオンラインの取り組みやコミュニケーションに参加しやすくなった。また、そのタイミングで僕はInfraStudyと呼んでいる大規模オンライン勉強会を企画し、運営してきた。 そういった様々なオンライン上の取り組みの中で「オフラインだったら夜の勉強会や懇親会に参加できるけれど、オンラインだったら家族もいるし難しい」といったような話を聞くことが増えてきた。その時僕は、正直、なぜ
GMOペパボ株式会社を退職しました - 人間とウェブの未来
本日、2018年9月28日が最終出社日でした。正式には10月末をもって、チーフエンジニアとして務めたGMOペパボ株式会社、また、主席研究員として務めたペパボ研究所を退職します。 現職には2015年4月に入社後、実際には入社前から関わりがあったため、それも含めると約4年間、本当に様々な取り組みを行ってきました。チーフエンジニア兼主席研究員として取り組んできた仕事の中で、社外にアウトプットして伝えてきたこと以外の、より社内業務的な内容はなかなか言語化する機会がなかったので、それらを振り返りつつ、転職に至った経緯をお話ししてみます。 2015年入社当時のペパボ福岡の雰囲気は今でもよく覚えており、良くも悪くも様々なところで血気盛んなメンバーによる争いの絶えない雰囲気がありました。 レンタルサーバ、所謂ホスティングサービスという歴史あるサービスを運営していることもあり「Webサービスに関する知見やア
OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する - 人間とウェブの未来
今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法（PoC）について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには，負荷の状態に基いて適切なインスタンスの数を決定し，必要以上にコンピュータリソースを使用しないように設計することも重要である． 単一のサーバに高集積にホストが収容可能であり，ホスト単位でのリソース管理を適切に行いながら，セキュリテ
メール送受信システムを幸せにするべく受信サーバdovecotのmruby拡張を書き始めた - 人間とウェブの未来
以前、メール送信（SMTP）サーバの振る舞いを制御するために、mrubyで機能拡張できるpmilterというMilterプロトコルベースのミドルウェアを作りました。 hb.matsumoto-r.jp その流れで、メール受信（POPやIMAP）サーバの振る舞いも同様に制御することによって、トータルでメール送受信システムの流量制限だけでなく、アクセス制御や不正な認証の検知、DoSのようなアクセスや大量メールの送受信をうまくプログラマブルな設定を書くことによって解決していきたいと思いはじめ、昨日からpmilterだけでなくメール受信サーバの開発にも取り組みはじめました。 それらのメール系ミドルウェアを組み合わせることにより、既に使われているメールの定番ミドルウェア（Postfixやdovecot）はそのままに、平易に導入できて、性能を落とすことなく自由にRubyで拡張ができるようになる基盤を作
ngx_mrubyで最初のHTTPSアクセス時に自動で証明書を設定可能にするFastCertificateの提案とPoC - 人間とウェブの未来
Let’s EncryptやACMEプロトコルによるDV証明書取得の自動化に伴い、証明書の取得と設定が簡単になってきました。 一方で、ACMEをツール化したものが増えるに従って、ACMEってそもそもどういう動きになっているのか、とか、自分たちの用途でどういう使い方がありえるのかとかが余計にわかりにくくなってきており、どこまで自動化できるかもよくわからない場合が多いのではないでしょうか。 そこで、 ドメインとAレコードの紐付けさえしていれば、最初のアクセス時に自動で証明書をとってきて、HTTPS通信にできないか というような、いわゆる FastCertificate 的な動きを実現したいと考え、ACMEの通信の中で各種処理を別のスクリプトでhookできるdehydratedとngx_mrubyを応用して実現可否も含めてPoCを実装してみました。 ※ FastContainerという考え方につ
PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来
RubyKaigiに行くと本にサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン（コンテナ環境構築の基盤ツール）があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
技術的アウトプットが必要な時代に求められる心構えと社外発表の頻度を増やす事の副次的効果 - 人間とウェブの未来
この話については、僕が専門としているWebサービス関連の業界におけるお話だと思って下さい。ただ個人的には、もう少し広範囲でも適用できる話なのではないかなとも思っています。 ということで、早速アウトプットすることのメリットから簡単に今の現状をまとめて今後エンジニアはどういう心構えで取り組んでいけば良いか、その中で、社外発表することのメリット、その社外発表の頻度を高める事の副次的効果についてまとめていきます。 アウトプットすることのメリット アウトプットする事やOSS化する事のメリットは、自分も含めて最近随分と語られるようになってきております。ここではそれについてあまり詳細に語る事は省略して、メリットを箇条書きでまとめると、 自分の技術が整理され、振り返りも容易になる フィードバックが得られる 自分の技術とその他社外のエンジニアと技術を足しあわせての技術検討（開発）が可能になる 自社だけでなく
IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来
先日、慶応義塾大学で開催された情報処理学会全国大会のトリのビッグイベントであるIPSJ-ONE2016で登壇してきました。 IPSJ-ONEとは、 IPSJ-ONEは、時流に乗る日本の若手トップ研究者19名によるライトニングトーク形式の登壇を俯瞰することで、 今後の情報社会に向けての研究動向を広く一般の人々に発信するために企画されました。 今、最先端研究を知ることは、ビジネスや学生の進路決定、メディア戦略などに繋がります。 「IPSJ-ONE」では、そうした最先端研究を一流の研究者による平易な解説で聞くことができます。 情報処理学会では、現在39分野の研究会にて各分野の専門家たちが日々議論を深めています。 今回も昨年に引き続き、各研究会による推薦、IPSJ-ONE企画・実施委員会による審査により、分野を超えたインパクトを有する19名の気鋭の研究者を招待いたしました。 それぞれ約5分の持ち時
HTTP/2へのmruby活用やこれからのTLS設定と大量証明書設定の効率化について - 人間とウェブの未来
Webサービス事業者として僕が先行して調査したり研究・開発している技術の中で、Webサーバ設定におけるHTTP/2とそのmruby活用についてや、PFS（Perfect Foward Secrecy）を考慮したTLS設定と大量証明書設定の効率化について、社内のインフラエンジニア向けに技術共有を行いました。 内容としては、まずはざっくりと知ってもらう事を目的に、細かい要素技術について深く立ち入り過ぎない程度に、今後弊社でのWebサービスのインフラ技術周りのアーキテクチャを考える上で必要になりそうな事を中心にお話しましたので、少し汎用性に欠けるかもしれません。 特に技術的に見せられないような話ではないので、参考程度に公開しておきます。どこかで喋って欲しいみたいな依頼は随時受け付けておりますので、お気軽にお問い合わせ下さい。 以下の二本立てです。 HTTP/2とmrubyの活用 HTTP/2時代
Webサーバのベンチマークツールはh2loadが便利 - 人間とウェブの未来
Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:
Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
