タグ

ブックマーク / blog.yuuk.io (27)

  • Linux eBPFトレーシング技術の概論とツール実装 - ゆううきブログ

    eBPF(extended Berkley Packet Filter)という用語を著者が初めてみかけたのは、2015年ごろだった。最初は、eBPFをその字面のとおり、パケットキャプチャやパケットフィルタリングを担うだけの、Linuxの新しいサブシステムであろうと認識していた。しかし、実際にはそうではなかった。 システム性能の分析のための方法論をまとめた書籍Systems Performance 1 の著者で有名なBrendan Greggが、Linuxのネットワークサブシステムとは特に関係ない文脈で、古典的なシステム性能計測ツールでは計測できないことを計測するツールを作っていた。その計測ツールがeBPFという技術によって実装されていることを知ったときに、eBPFに興味をもったのだった。また、eBPFは、システム性能を調べる用途以外にXDP(eXpress Data Path)と呼ばれるプ

    Linux eBPFトレーシング技術の概論とツール実装 - ゆううきブログ
  • さくらインターネット研究所での1年 - ゆううきブログ

    さくらインターネット株式会社に昨年の2月に入社してから1年(と2ヶ月)が経過した。さくらインターネット研究所での研究員としての新しい働き方にも慣れてきた。論文や口頭発表などの締切も落ち着いてきたので、ここまでの1年を振り返ってみる。 やりたいことに集中できる 広範なインフラ技術 自身の研究テーマ 日々の活動 むすび やりたいことに集中できる さくらインターネット研究所では、自分を取り戻してやりたいことに集中できる自由な研究環境がある。 好きでやっていたはずの開発や運用がだんだん会社や他人のためだけのの仕事になってきて疲れてしまった人は、自分を取り戻して技術に向き合っていける恵まれた環境として、さくらインターネット研究所おすすめです。— ゆううき (@yuuk1t) 2019年4月3日 さくらインターネット研究所では、テーマは与えられることはなく、自分がおもしろいと思うテーマを設定する。成果

    さくらインターネット研究所での1年 - ゆううきブログ
  • はじめて国際会議で論文発表して考えたこと - ゆううきブログ

    先日、アメリカのウィスコンシン州ミルウォーキーで開催された国際会議 IEEE COMPSAC 2019で時系列データベースHeteroTSDBの論文を発表してきました。 IEEE COMPSACは、IEEE内のコンピュータソフトウェア分野の分科会IEEE Computer Societyのフラグシップカンファレンスとして開催されている国際会議です。 COMPSACが対象とする分野は、ソフトウェア、ネットワーク、セキュリティ、アプリケーションなど非常に幅広く、様々なテーマの発表がありました。 COMPSACは、メインシンポジウムと併設のワークショップにより構成されており、メインシンポジウムのregular paperの採択数は63(24.5%)、short paperの採択数は50となっています。 投稿時にregularとshortの区別はなく、今回の我々の論文は、メインシンポジウムのs

    はじめて国際会議で論文発表して考えたこと - ゆううきブログ
  • 株式会社はてなを退職しました - ゆううきブログ

    2018年12月21日の今日がはてなでの最終出社日となりました。 はてなには、2013年12月に新卒として入社し、その後5年間に渡りお世話になりました。 はてなとの出会いのきっかけは、2011年のはてなインターンに参加したことでした。 はてなインターンの特徴の一つに、ほとんどの参加者が参加したときの内容をブログ記事として書いていることがあります。インターン参加記事には、技術やWebに対する大きな熱量がこもっており、すっかり自分もWeb技術をやっていくのだと感化されました。 ダメ元で選考に望んだところ、運良く選考通過のお知らせをいただいてとてもうれしかったことを今もよく覚えています。 そこから毎年インターンの参加者をみてきていますが、とてもハイレベルで、よく自分が選考通過したものだと今でも思います。 この出来事が自身の人生にとって大きな転機だったと言えるでしょう。 インターンの1年後にアルバ

    株式会社はてなを退職しました - ゆううきブログ
  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

    先月投稿した2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介しました。 今回は、前回同様、主に新卒Webエンジニア向けに、Webアプリケーションサーバとデータベースサーバ間の接続管理モデルと運用事情について紹介します。 データベース接続の永続化やコネクションプーリングとは何なのか、なぜ必要なのかといったことが主な話題です。 背景 データベース接続の永続化とはなにか データベース接続のオーバヘッド データベース接続の永続化手法 コネクションプーリングとはなにか コネクションプーリング: ドライバ型 コネクションプーリング: プロキシ型 コネクションプーリング全体について PostgreSQLMySQL 参考資料 まとめ 背景 2015年Webサーバアーキテクチャ序論では、Webサーバアーキテクチャの話とWebアプリケーショ

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
    ya--mada
    ya--mada 2018/11/05
  • 高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ

    名古屋大学で開催されたIPSJ-ONE2017 で登壇しました。 IPSJ-ONEというのは、情報処理学会の各研究会から選ばれた日の若手トップ研究者17人が集まり、自身の研究を高校生でもわかるように発表するイベントです。 1000人ぐらい入る講堂で、しかもニコニコ生放送で配信されるというとても大掛かりなイベントです。 ちなみに、昨年は、同じ研究会からの推薦で、 id:matsumoto_r (matsumotory) さんが登壇されています。 IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来 発表 「高度に発達したシステムの異常は神の怒りと見分けがつかない」という、一見何の話かわからないやばそうな話なんですが、大真面目に話してきました。 スライドを以下に公開しています。ただ、スライドだと何の話をしているかおそらくわからな

    高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ
    ya--mada
    ya--mada 2018/05/17
  • GoとMySQLを用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ

    【追記】2023年3月21日 YAPC::Kyoto 2023で、ジョブキューシステムFireworqの設計と運用実績も含めて発表されました。id:tarao ++ 【加筆修正】 2020年2月16日 執筆時から6年も経過していますが、たまたまこの記事を振り返る機会があったので、日語がおかしいところを一部修正したり、一緒に取り組んだ方々の名前が書かれていなかったところを修正しました。 【追記】2017年12年24日 このエントリのジョブキュー実装がFireworqという名でOSSとして公開されました。id:tarao ++ github.com この記事ははてなエンジニアアドベントカレンダー2014の4日目です。 前回は Mackerelで採用している技術一覧とその紹介 - Hatena Developer Blog でした。 社内の開発合宿で、 id:taraoさん、id:hakobe

    GoとMySQLを用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ
  • ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ

    はてなエンジニア Advent Calendar 2017の2日目です。 昨日は、id:syou6162 さんによるAWS Lambda上で鯖(Mackerel)の曖昧性問題を機械学習で解決しよう - yasuhisa's blogでした。 この記事は、人工知能学会 合同研究会2017 第3回ウェブサイエンス研究会の招待講演の内容を加筆修正したものです。 講演のテーマは、「自然現象としてのウェブ」ということでそれに合わせて、「自然のごとく複雑化したウェブシステムの運用自律化に向けて」というタイトルで講演しました。 一応、他の情報科学の分野の研究者や技術者に向けて書いているつもりですが、その意図がうまく反映されているかはわかりません。 概要 1. ウェブシステムの信頼性を守る仕事 2. ウェブシステム運用の現状 国内のウェブシステムの運用技術の変遷 クラウド時代 コンテナ型仮想化技術 サーバ

    ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ
  • コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ

    概要 Lambdaは100msの実行時間単位でオンデマンドに課金されるため、立ち上げっぱなしのEC2インスタンスよりも、料金が安くなる可能性があることが一般に知られている。 しかし、以下の性質を満たすアプリケーションでは、EC2インスタンス上に構築したケースと比較して、Lambda上に構築したほうがコスト効率が悪くなるのではないかと考察してみた。 Lambda functionの実行時間のうち、ネットワークI/O時間が支配的である Lambda functionの実行終了を同期的に待たなければならない 複数のレコードをLambda functionの引数に渡すことができない Lambdaの基コスト構造 まず、Lambdaのコスト構造を把握する。 Lambdaの料金表[1]によると、「functionに対する合計リクエスト数」と「functionの合計実行時間」に応じて料金が発生する。 後

    コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
    ya--mada
    ya--mada 2017/11/06
    スケールアップ、多重化で処理時間が短くならない、とかでは不利と。たまにキックされる場面しか思いつかないからコスト試算が
  • RedisサーバのCPU負荷対策パターン - ゆううきブログ

    Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R

    RedisサーバのCPU負荷対策パターン - ゆううきブログ
  • 2015年Webサーバアーキテクチャ序論 - ゆううきブログ

    2023年03月31日追記:この記事を基に、@sadnessOjisanさんより、コードレベルにより踏み込んだ、かつ、グリーンスレッドベースの新しいWebサーバアーキテクチャも含めて整理された記事 Webサーバーアーキテクチャ進化論2023 | blog.ojisan.io が公開されました。 主に新卒のWebエンジニア向けに、古典的なWebサーバアーキテクチャを学ぶ道のりと代表的な実装モデルの概要を紹介します。 この辺りの話題がWeb界隈で流行っていたのは数年以上前というイメージですが、Webサービスは相変わらずWebサーバの上で動いているので、流行り廃り関係なく学ぶべき内容だと思っています。 また、HTTP/2がいよいよRFC化し、既にh2oやtrusterdなどのHTTP/2のサーバ実装があり、今後Webサーバアーキテクチャを再訪することが増えるような気がしています。 ところが、We

    2015年Webサーバアーキテクチャ序論 - ゆううきブログ
  • 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ

    サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDBAmazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇

    時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
  • Googleが数千台もある10年前のLinuxディストリをライブアップグレードした話 - ゆううきブログ

    Googleが、太古のディストリビューションであるRed Hat 7.1から、10年新しいDebianベースのディストリビューションへ、ライブアップグレードした話を紹介する。 そのあと、自分の身の回りの環境と比較し、参考にすべきポイントを考察する。 原文は USENIX LISA の投稿論文だ。しかし、中身は論文体というよりは、事例の紹介といった適切かもしれない。 MERLIN, M. Live Upgrading Thousands of Servers from an Ancient Red Hat Distribution to 10 Year Newer Debian Based One. In Proceedings of the 27th conference on Large Installation System Administration (LISA) (2013),

    Googleが数千台もある10年前のLinuxディストリをライブアップグレードした話 - ゆううきブログ
  • 自作Linuxコンテナの時代 - ゆううきブログ

    最近、Docker以外のコンテナ型仮想化技術の流れとして、自作コンテナエンジンの時代が来るのではないかと感じている。 自作コンテナエンジンとは、コンテナ型仮想化技術を構成する個々の要素技術を組み合わせ、自分の用途にあわせて最適化したコンテナエンジンのことだ。 他のOSのコンテナ仮想化技術について疎いため、以下ではLinuxに限定して話を進める。 概要 Dockerも含めて、Linuxコンテナはコンテナを構成する複数の要素技術の組み合わせである。自分のやりたいことに対して、Dockerをはじめ既存のコンテナエンジンが複雑すぎるケースがある。そこで、自分の用途にあわせてコンテナエンジンを自作することを考えてみる。libcontainerに代表されるように、Linuxコンテナエンジンを自作しやすい環境が整いつつある。今後は、巨大なコンテナエンジンに対して、UNIX哲学に基づいて制御可能な小さなコ

    自作Linuxコンテナの時代 - ゆううきブログ
  • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

    この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、PerlScalaGoもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談

    ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
  • Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

    主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認(w) サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認(df) 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /

    Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
    ya--mada
    ya--mada 2016/02/18
    前提が星井な。
  • Serverspec + Mackerel APIによるインフラテストの実運用化 - ゆううきブログ

    この記事は Mackerel Advent Calendar 2015 の24日目の記事です。 前回は、id:hitode909 による 三度の飯より監視と通知!Mackerelで自分の心拍数を監視しよう - hitode909の日記 でした。 今回は、Mackerel APIを用いてServerspecによるサーバ構成テストを実運用化した話を紹介します。 Serverspec単体では手の届かないかゆいところをMackerelでサポートするところがポイントです。 Mackerelはもちろんですが、他のサーバ管理ツールにも通用する汎用的な話になるように心がけています。 Serverspec導入の背景 Serverspec Serverspec × Mackerel ロール単位でspecを書く ディレクトリレイアウト Thorfile サーバ上でServerspecをローカル実行する あとがき

    Serverspec + Mackerel APIによるインフラテストの実運用化 - ゆううきブログ
  • はてなで大規模サービスのインフラを学んだ - ゆううきブログ

    中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ

    はてなで大規模サービスのインフラを学んだ - ゆううきブログ
    ya--mada
    ya--mada 2015/12/18
  • Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ

    この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー

    Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
  • Go言語によるCLIツール開発とUNIX哲学について - ゆううきブログ

    この記事ははてなエンジニアアドベントカレンダー2014の8日目です。 今回は、Go言語でサーバ管理ツール Mackerel のコマンドラインツールmkr を作るときに調べたこと、考えたこと、やったことについて紹介します。(mkr は現時点では開発版での提供になります。) コマンドラインツールについて コマンドラインツールを作るにあたって、@deeeet さんの YAPC Asia 2014 での発表資料が非常に参考になります。 書籍 UNIXという考え方ーその思想と哲学 の内容をベースに、コマンドラインツールはどうあるべきかということが丁寧に説明されています。 上記資料から引用させていただくと、コマンドラインツールにおいて重要なポイントは以下の7つであるとされています。 1つのことに集中している 直感的に使える 他のツールと連携できる 利用を助けてくれる 適切なデフォルト値を持ち設定もでき

    Go言語によるCLIツール開発とUNIX哲学について - ゆううきブログ
    ya--mada
    ya--mada 2014/12/09