タグ

ブックマーク / hb.matsumoto-r.jp (16)

  • ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類 - 人間とウェブの未来

    前回のエントリでは,分散型データセンターOSの背景と概要について述べた. hb.matsumoto-r.jp エントリでは,さくらインターネット研究所としてのフォーカス領域に基づいて、分散型データセンターOSからさらに踏み込んだ、ユビキタスデータセンター(命名 id:y_uuki )としての目的と解釈を紹介し,その文脈で,各社研究開発しているコンテナ実行環境,すなわち,コンテナランタイムにおけるOCIランタイム(Low-Level runtime)がどのように分類できるかを具体的に整理する. ユビキタスデータセンターOSとは ユビキタスデータセンターOSの役割 コンテナ実行環境とは コンテナ実行環境の分類 プロセス型 サンドボックス型 ユニカーネル型 microVM型 VM型 リアクティブ性の高いコンテナ実行環境の必要性 まとめ 大規模なデータセンターを建設し,ハードウェアリソースを集約

    ユビキタスデータセンターOSの文脈におけるコンテナ実行環境の分類 - 人間とウェブの未来
  • OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する - 人間とウェブの未来

    今回は、Webサーバの実装に依存することなく、OSレイヤでWebサーバソフトウェアが起動時に実行するであろうシステムコールを監視して、そのタイミングでプロセスをイメージ化する方法(PoC)について紹介します。 その前に、まずは前提の一致ということで、僕は以前から、Webサーバプロセスの性質について、プロアクティブ性とリアクティブ性という分類について述べてきました。 プロアクティブ性とリアクティブ性について簡単にまとめると、以下のようになります。 Webサーバ機能のプロアクティブ性とリアクティブ性 突発的なアクセス集中のような変化に耐えうるシステムを構築するためには,負荷の状態に基いて適切なインスタンスの数を決定し,必要以上にコンピュータリソースを使用しないように設計することも重要である. 単一のサーバに高集積にホストが収容可能であり,ホスト単位でのリソース管理を適切に行いながら,セキュリテ

    OSレイヤでWebサーバが起動時に実行するシステムコールを監視し起動完了直前のプロセスをイメージ化する - 人間とウェブの未来
    defiant
    defiant 2018/04/24
  • 2018年の抱負 - Webホスティングサービスの技術を体系化したこととその意図について - 人間とウェブの未来

    2018年の電子情報通信学会論文誌BのVolume J101-B No.1(発行日:2018/01/01)「ネットワーク社会に向けたインターネットアーキテクチャ論文特集」に、我々が執筆した「Webサーバの高集積マルチテナントアーキテクチャと運用技術」という招待論文が掲載されました。オープンアクセスで誰でもダウンロードして読むことができますので是非ご覧下さい。 2018年のIEICE論文集の第1号に我々が執筆した「Webサーバの高集積マルチテナントアーキテクチャと運用技術」という招待論文が掲載されました。オープンアクセスですので是非ご覧下さい。 / “IEICE SEARCH SYST…” https://t.co/LbYkHPDQg4— 松 亮介 / まつもとりー (@matsumotory) 2018年1月1日 また、論文誌の最初に吉田先生による「ネットワーク社会に向けたインターネット

    2018年の抱負 - Webホスティングサービスの技術を体系化したこととその意図について - 人間とウェブの未来
  • 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題 - 人間とウェブの未来

    一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ!マネージドクラウド」というロリポップ!の新しいプランのリリースに向けて取り組みを行ったりしておりました。 hb.matsumoto-r.jp そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。 英文タイトルは、 A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes です。 はじめに 背景 目的 提案の概要 Serverlessアーキテクチャによる実装との違い Her

    実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題 - 人間とウェブの未来
  • Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測する簡単な方法 - 人間とウェブの未来

    単純に特定のURLに対してミドルウェアの性能を計測したい場合などには、今でもabやwrk、h2loadのようなシナリオベースではないシンプルなベンチマークはとても有用です。 一方で、最近ではgatlingやtsungといった、豊富な機能やリッチな計測結果を取得できるベンチマークソフトウェアも豊富になってきました。 ただ、例えば、単に「Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測したい」時に、僕のようなめんどくさがりの人間はcliで適当にオプションを渡して1回の実行でシュシュシュっと取りたいものですが、それができるツールが見当たらず、うーむ、gatlingやtsuningでやるかなぁとおもっていたところ、なんとApache Bench(ab)で簡単にシュシュシュっとできてしまうことに気づいたのでした。 ということでその方法を紹介します。例えば以下のような要件の時に

    Webサーバのベンチマーク結果をレスポンスタイムの時系列データとして計測する簡単な方法 - 人間とウェブの未来
  • ApacheとPHPが動くコンテナにUID/GIDの空間を動的に割り当ててhaconiwaで起動させる - 人間とウェブの未来

    hb.matsumoto-r.jp 前回の記事では、PHPが動くApacheのコンテナをhaconiwaを使って沢山起動しました。しかし、前回のコンテナは、 同じコンテナイメージがあるディレクトリを複数コンテナで共有している ホストから見てもuid/gidがapacheで全て起動している pidもホストとコンテナで共有している というように、コンテナとホストの空間が混在した状況になっていました。そこで、今回はさらに踏み込んで、よりコンテナを独立した環境にするべく、 動的にコンテナイメージのtar.gzからそれぞれの独立したコンテナ用のディレクトリを用意する 動的に各コンテナにホストuid/gidレンジを切り出し、コンテナ内ではuid=0からレンジの数だけマッピングする 例えば100個のuidレンジ(80000 ~ 80099)をコンテナ内では(0 ~ 99)とみなせるようにする 動的にマ

    ApacheとPHPが動くコンテナにUID/GIDの空間を動的に割り当ててhaconiwaで起動させる - 人間とウェブの未来
  • PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来

    RubyKaigiに行くとにサインを求められるすごいエンジニアが書いたhaconiwaというmruby製のコンテナエンジン(コンテナ環境構築の基盤ツール)があるのですが、少し試してみようと思って、とりあえず1サーバ上に1万コンテナぐらい動かそうとしてみました。久々に今回は自分の作ったOSSではなく、OSSの検証レポート的な記事になります。 haconiwaは僕の好きなOSSの一つで、それはなぜかと言うと、 haconiwaでコンテナを作る際に、haconiwa実行環境にはコンテナの要素機能が全て入っている必要はない 必要なコンテナの要素機能を簡単に組み合わせて、自分が実現したいコンテナ、あるいは、それに準ずる環境を作れる haconiwaによるコンテナ定義をRubyのDSLで表現でき、動的な設定や組み合わせの設定を簡単にかける ということができるからです。その特性から、CentOS6のよ

    PHPが動くApacheのコンテナ環境をhaconiwaで1万個動かそうとしてみた - 人間とウェブの未来
  • Pmilter: Programmable Mail Filter Serverを作った - 人間とウェブの未来

    Pmilterというサーバソフトウェアを作りました。 github.com PmilterはProgrammable Mail Filterの略で、SMTPサーバ(送信や受信)とmilterプロトコルで通信し、SMTPサーバの送受信の振る舞いをRubyでコントロールできるサーバソフトウェアです。 これまでにも、milter managerやRubyのgemを使ってmilterサーバを作るといった素晴らしいソフトウェアがありました。ですが、今回僕がフルスクラッチで作りたかった理由としては、 とにかくインストールや設定がシンプルで運用しやすいサーバソフトウェアにしたい ミドルウェアとして振る舞いを設定する感覚でRubyで制御する事に専念したい 依存ライブラリを減らしワンバイナリでサーバに配置できるようにしたい 設定変更に再起動することなくRubyを変更するだけで振る舞いを変えられるようにしたい

    Pmilter: Programmable Mail Filter Serverを作った - 人間とウェブの未来
  • 博士課程の予備審査にいってきました - 人間とウェブの未来

    僕が博士課程で研究していた「Webサーバの高集積マルチテナントアーキテクチャに関する研究」という内容で、僕が通っている京都大学大学院情報学研究科博士課程の予備審査にいってきました。研究室は岡部研究室になります。 予備審査は、僕が所属する大学院の場合、基的には博士課程の研究で3以上ジャーナルを通す事を条件に、内容的にも指導教員の許可が受けられれば予備審査へと進むことができます。 博士課程においては、博士課程の入学資格審査の面接で情報学研究科のほぼ教員全員(数十人)の前でプレゼンし、博士課程が半分経過した際に受ける中間審査のプレゼン(これまた同様に教員数十人)に続く、大変厳しい審査のうちの一つです。プレゼン時間は1時間、質疑応答は30分です。また、そこに参加される先生方は、各専門分野でも世界トップクラスの研究者であるため、そのような方々の前で学術研究の発表をするのは、とにかくプレッシャーと

    博士課程の予備審査にいってきました - 人間とウェブの未来
  • 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に起因する高負荷問題から、システムコールやカーネ

    CPU使用率100%のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
  • 1月から5月の技術関連の登壇資料まとめと振り返り - 人間とウェブの未来

    1月から上期がはじまり、昨年は出産関連などで9月を最後にあまり登壇できていなかったので、今年は頑張るぞ〜と意気込んでいたわけですが、怒涛のように登壇依頼がやってきて、やばいこれはきついぞ!と思いながらもなんとか一段落するところまでやり切れたのでちょっとどこかに旅にでたいです。 その前に、結構登壇して色々喋ったり資料作ったりしたので、時系列でまとめておきます。 今期は技術カンファレンスだけでなく、学術研究方面でも発表できたので、自分の立ち位置としてはわりと網羅的に発表できたかなと思います。 全体 まずは以下に1月から5月までの全体の発表実績をリスト化しました。 松亮介, ロリポップ!で目指すPHPのためのセキュリティと性能要件を同時に満たすサーバホスティング技術, PHPカンファレンス福岡2016, 2016年5月. 松亮介, なめらかなシステムのアイデアと概要設計: 生命の観点からWe

    1月から5月の技術関連の登壇資料まとめと振り返り - 人間とウェブの未来
    defiant
    defiant 2016/05/23
  • HTTP/2へのmruby活用やこれからのTLS設定と大量証明書設定の効率化について - 人間とウェブの未来

    Webサービス事業者として僕が先行して調査したり研究・開発している技術の中で、Webサーバ設定におけるHTTP/2とそのmruby活用についてや、PFS(Perfect Foward Secrecy)を考慮したTLS設定と大量証明書設定の効率化について、社内のインフラエンジニア向けに技術共有を行いました。 内容としては、まずはざっくりと知ってもらう事を目的に、細かい要素技術について深く立ち入り過ぎない程度に、今後弊社でのWebサービスのインフラ技術周りのアーキテクチャを考える上で必要になりそうな事を中心にお話しましたので、少し汎用性に欠けるかもしれません。 特に技術的に見せられないような話ではないので、参考程度に公開しておきます。どこかで喋って欲しいみたいな依頼は随時受け付けておりますので、お気軽にお問い合わせ下さい。 以下の二立てです。 HTTP/2とmrubyの活用 HTTP/2時代

    HTTP/2へのmruby活用やこれからのTLS設定と大量証明書設定の効率化について - 人間とウェブの未来
  • 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サーバのベンチマークツールはh2loadが便利 - 人間とウェブの未来
  • mrubyでHTTP/2の画像変換サーバを作った - 人間とウェブの未来

    この記事は、mruby advent calendar 2015の16日目の記事です。 画像やstaticコンテンツ配信系はHTTP/2が有利な状況が幾つかあるので、ついでにHTTP/2を喋る画像変換サーバのプロトタイプをmrubyで作ってみました。ベースはもちろんtrusterdです。なんていったってmrubyのHTTP/2サーバですからね!! 最近また開発を再開しておりまして、昔はh2oやnghttp2のベンチマークに一緒に比較対象として入れてもらったりしていたのですが、しばらく離れているうちに皆さん先へ先へと行ってしまわれたので、また追いつけるようにセッセと勉強しながら実装しだしております。 github.com その他、trusterdについてはこの辺とか、 qiita.com この辺を見ていただくと良いかと思います。 hb.matsumoto-r.jp trusterdのビルド

    mrubyでHTTP/2の画像変換サーバを作った - 人間とウェブの未来
    defiant
    defiant 2015/12/16
  • コマンド実行時のCPUやIOリソースを簡単に制御するツールrconを作った - 人間とウェブの未来

    CPUやメモリ、IOといったリソースの制限下でとあるコマンドを実行させたい場合に、cgroup上に何かgroupを作ったりしてからcgexecを実行して、実行後はそのgroupを消す、といったような一手間かかる方法がほとんどでした。 実行後のgroupも綺麗にしたい、といった所まで考えるとなかなか手間がかかっていたので、それらを全てワンラインでできるrconというワンバイナリで動くツールを作りました。 github.com 例えば、負荷サーバでの調査ツールを流す際に、CPUとかIOとかを制限しつつドロドロ実行したい場合等に便利です。Linuxcgroup対応した環境でのみ動きます。 使い方 ほぼREADME通りなのですが、オプションは代替以下のようになっています。 --memは変なので--memoryに変更しました!! ./rcon --help Usage: rcon [options

    コマンド実行時のCPUやIOリソースを簡単に制御するツールrconを作った - 人間とウェブの未来
  • Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来

    という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、3行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い

    Webオペレーションエンジニアのアウトプットと開発力 - 人間とウェブの未来
    defiant
    defiant 2015/06/02
  • 1