タグ

yuukiに関するtomomiiのブックマーク (41)

  • “LLM for SRE“の世界探索 - ゆううきブログ

    ChatGPTが登場した当初、対話や要約、翻訳、コード生成などの典型的な言語タスクができても、SREやAIOpsの研究開発にはあまり関係ないのではないかと正直思っていた。AIOpsでは典型的にはいわゆるObservabilityデータ(メトリクス、ログ、トレースなど)が入力となるため、自然言語ではなく数値のデータを解析することが求められる。自然言語のタスクを研究対象としていなかったため、AIOpsとChatGPTに強い関係性は見いだせなかった*1。 しかし、自分で大規模言語モデル(Large Language Model: LLM)を日常的に使用したり、表題にあるようにSREのためのLLM(LLM for SRE, LLM4SRE)に関する論文を読むうちに、LLMのテキスト生成器としての性質よりもその優れた推論機械としての性質に注目するようになった。特にSREの障害診断は、人間の専門家が推

    “LLM for SRE“の世界探索 - ゆううきブログ
  • エンジニアのためのSRE論文への招待 - SRE NEXT 2023 - ゆううきブログ

    この記事では、2023年9月29日に開催されたSRE NEXT 2023 IN TOKYOでの講演の概要に加えて、講演では触れられなかった部分の補足と、発表を終えての後記、最後にSRE NEXT全体の感想を書きました。 SRE NEXT 2020の基調講演に招いていただいたところから始まり、昨年のSRE NEXT 2022の公募セッションでも発表し、今回で3回目の発表になりました。今回の講演は、SRE NEXTの「NEXT」と価値観の一つである「Diversity」を踏まえて、自身のエンジニアと研究者の両方の経験を活かして、SREを深く実践する上で、技術論文を探して読むアプローチを提示するものです。昨今の国内のSREコミュニティでは組織的実践に主な関心が移っている状況と対比させて、コンピュータサイエンスに基づく技術的挑戦の可能性を示唆する意欲的な講演を目指したつもりです。 この講演での主要

    エンジニアのためのSRE論文への招待 - SRE NEXT 2023 - ゆううきブログ
  • リモートワークによる孤立から結束へと向かうチームビルディング

    カテゴリー DX (2) 一般 (58) 研究会 (6) 働き方 (4) 技術 (351) Edge AI (2) Edge Computing (12) Erlang (1) FIWARE (2) Fog Computing (9) Infiniband (31) Internet of Things (32) Key Value Store (17) Linux (3) Linux KVM (10) Machine Learning (4) RealTime Web (14) SRE (2) Webサービス (42) インフラ (7) コンテナ (3) ストレージ (92) データセンター (7) データベース (47) データ流通 (6) テレプレゼンス (2) ネットワーク (214) 仮想化 (110) 災害コミュニケーション (26) 空間情報 (30) 量子コンピューティング

    リモートワークによる孤立から結束へと向かうチームビルディング
  • AIOps研究録―SREのための
システム障害の自動原因診断 / SRE NEXT 2022

    SRE NEXT 2022講演。 https://sre-next.dev/2022/schedule/#jp37

    AIOps研究録―SREのための
システム障害の自動原因診断 / SRE NEXT 2022
  • ITエンジニアから研究者へ。社会人博士として大学院にも再挑戦し、自分の「代表的プロダクト」を追求するわけ - Findy Engineer Lab

    こんにちは、坪内佑樹です。Web上では、ゆううき(@yuuk1t)と呼ばれています。 僕は現在、さくらインターネット研究所で研究員を務めています。専門領域は、ITエンジニアが情報システムに対して常に変化をもたらしながら、同時に情報システムの信頼性を高めていくための技術である、Site Reliability Engineering(SRE)です。 これまで、大学院を中途退学したのち、Webサービス企業でWebオペレーションエンジニアおよびSREを5年間務めました。そして昨年(2019年)の2月から現職で研究開発に取り組んでおり、今年はさらに情報系の大学院の博士課程に社会人博士として進学します。 記事では、昨今注目を浴びているSRE分野において「代表的プロダクト」を作ることに憧れ、それを目標の軸に据えて、なぜエンジニアから研究者になる「選択」をしたのかをご紹介します。 大学で研究するより、

    ITエンジニアから研究者へ。社会人博士として大学院にも再挑戦し、自分の「代表的プロダクト」を追求するわけ - Findy Engineer Lab
    tomomii
    tomomii 2020/05/14
    歩みを進めながら所々でいろんな景色を見て感じて今のゆううきさんがあるのだなと感じます。随分前の"道"の話を大事にしてもらってありがとうございます
  • SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測 - エンジニアHub|Webエンジニアのキャリアを考える!

    SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測 SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹(ゆううき)さんが解説します。 こんにちは。SREの研究者をやっているゆううき(@yuuk1t)です。 SRE(Site Reliability Engineering)は、従来のオペレーションエンジニア、システム管理者(sysadmin)と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られる

    SRE実践の手引 ─ 信頼性をどう制御するか? から始める、現実的な指標と目標の設計と計測 - エンジニアHub|Webエンジニアのキャリアを考える!
    tomomii
    tomomii 2019/12/06
    組織にも置き換えられそうな考え方で興味津々です
  • Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ

    この記事は第5回Webシステムアーキテクチャ研究会の予稿です。 はじめに Webサービスにおいては、スマートフォンの普及によるアクセス増加に対してスケーラビリティを持ち、個人向けだけでなく企業向けサービスの可用性の要求に耐えられるようなシステム設計が必要とされている。 さらに、Webサービスが人々の生活に浸透したために、Webサービス事業者はサービスを長期間運用することが当たり前となっている。 その間、新機能開発、ソフトウェアの実行効率化、セキュリティ向上などを目的に、システム管理者は自身が管理するソフトウェア群を更新しつづける必要がある。 このような多様な要求を満たすために、Webサービスを開発・運用するエンジニアには、OSやデータベース、ネットワーク、分散システム、プログラミング言語処理系などのコンピュータ工学における広範囲の基礎知識と、ミドルウェア、オペレーション自動化のためのソフト

    Webシステムアーキテクチャの地図を描く構想 - ゆううきブログ
    tomomii
    tomomii 2019/10/04
    かっこいい! "既存の教科書だけでは学べないため、体系立てて学ぶことが難しくなっている。 そこで、Webシステム開発・運用の現場の経験を踏まえつつ、生きた知識の地図をつくることが重要となる"
  • はじめて国際会議で論文発表して考えたこと - ゆううきブログ

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

    はじめて国際会議で論文発表して考えたこと - ゆううきブログ
    tomomii
    tomomii 2019/07/29
    本来の目的を忘れて目先だけ見て楽そうだとか皆がこうだからと安きに流れ、思考することをやめたらいけない。どんどん意思決定することができなくなるだろうなと気づかされました
  • Mackerelで開発した時系列データベースについての論文がIEEEの国際会議「COMPSAC 2019」で発表されました - Hatena Developer Blog

    Mackerel チームのWebアプリケーションエンジニア id:astj です。 さくらインターネットさんのプレスリリースにある通り、はてなMackerelチームより、私 id:astjと、同じくWebアプリケーションエンジニアの id:itchynyも執筆に参加した論文「HeteroTSDB: An Extensible Time Series Database for Automatically Tiering on Heterogeneous Key-Value Stores(HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ)」が、IEEEの国際会議「COMPSAC 2019」に採択されました。 論文は、2019年7月15日~19日(現地時間)にアメリカ合衆国ウィスコンシン州で開催された「COMPSAC 2019」にて、

    Mackerelで開発した時系列データベースについての論文がIEEEの国際会議「COMPSAC 2019」で発表されました - Hatena Developer Blog
  • さくらインターネット研究所、国際会議「IEEE COMPSAC 2019」で論文採択 | さくらインターネット

    インターネットインフラサービスを提供するさくらインターネット株式会社(社:大阪大阪市、代表取締役社長:田中 邦裕)の組織内研究所であるさくらインターネット研究所に所属する研究員である坪内佑樹主著の論文が、国際会議「IEEE COMPSAC 2019」におけるメインシンポジウムの1つである「NCIW: Networks, Communications, Internet & Web Technologies」(以下、NCIW)にショートペーパーとして採択されました。アメリカ合衆国・ウィスコンシン州で現地時間2019年7月15日(月)~19日(金)に開催されたCOMPSAC2019にて、論文の発表を行いました。 ・論文の発表を行うさくらインターネット研究所 研究員 坪内 佑樹 論文は、異種混合キーバリューストアを用いて拡張可能な時系列データベースアーキテクチャを提案するものです。サーバ

    さくらインターネット研究所、国際会議「IEEE COMPSAC 2019」で論文採択 | さくらインターネット
  • SREの組織的実践 / Organized SRE

    博士課程での研究まとめ 2023年1月版 / Summary of my research in the PhD course

    SREの組織的実践 / Organized SRE
  • 2019年SRE考 - ゆううきブログ

    この記事では、自分が数年Site Reliability Engineering (SRE)を実践しつつ、SREについて考えてきたことをまとめる。 先月開催されたMackerel Drink Up #8 Tokyoと先日開催された次世代Webカンファレンス 2019では、SREについて集中的に議論する機会に恵まれたため、脳内メモリにキャッシュされているうちに、SREに関する私的な論考をまとめておく。 (以降では、SREの原著にならい、技術領域名を指すときはSRE、職種名を指すときにSREsと表記する。) SREとの関わり なぜSREに関心をもったのか 2015年にメルカリさんがSREチームを発足したときに、SREsの存在を知り、SREsはシステム管理者、Webオペレーションエンジニアインフラエンジニアといった既存の職種を置き換えていくものだと理解した。 当時、自分が注目したのは、SRE

    2019年SRE考 - ゆううきブログ
  • 株式会社はてなを退職しました - ゆううきブログ

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

    株式会社はてなを退職しました - ゆううきブログ
    tomomii
    tomomii 2018/12/22
    本当にお世話になりました。つねに挑戦しながら歩を進まれていて眩しい 研究員としてのご活躍も応援しています
  • 時系列データベースの論文を書いた - ゆううきブログ

    先週、第11回インターネットと運用技術シンポジウム (IOTS2018)にて、投稿した論文の発表をしてきました。 IOTSは査読付の国内の研究会であり、2年前に招待講演をさせていただいた研究会でもあります情報処理学会でウェブオペレーション技術について招待講演した話 - ゆううきブログ。 実は、そのときに、来年論文を投稿するぞと意気込んでいました。 実際にはそこから2年かかりましたが、この度論文を投稿することができました。 予稿 HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ スライド 実務から研究へ 今回投稿した論文の内容は、Mackerelで開発した時系列データベースに関するものです。 これらはすでにAWS Summit Tokyo 2017、Web System Architecture研究会で発表済みのものになります。 時

    時系列データベースの論文を書いた - ゆううきブログ
  • TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ

    著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは,一般的に,分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される. 相互にネットワーク通信するシステムにおいて,システム管理者があるネットワーク内のノードに変更を加えた結果,ノードと通信している他のノードに変更の影響がでることがある. ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど,システム管理者が個々の通信の依存関係を記憶することは難しくなる. さらに,常時接続しておらず必要なタイミングで一時的に通信するケースでは,あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない. その結果,システムを変更するときの影響範囲がわからず,変更のたびに依

    TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ
    tomomii
    tomomii 2018/11/24
    異なる領域の創意あふれる専門家が集い多様な分野の交点で議論を重ねてアイデアを展開していく会の文化がかいまみえる 楽しそうだしかっこいい!
  • サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ

    この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。 ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。 1. はじめに 2. アーキテクチャ アーキテクチャ概要 動作フロー データ構造 KVSの機能要件 3. 実装 実装概要 KVS間のデータ移動 データ位置の解決 費用特性 4. 考察と今後の課題 Diamondの欠点 将来機能 5. まとめ スライド

    サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ
  • RedisサーバのCPU負荷対策パターン - ゆううきブログ

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

    RedisサーバのCPU負荷対策パターン - ゆううきブログ
  • 2017年のエンジニアリング振り返り - ゆううきブログ

    はてなに入社して4年経った。 入社4年成功https://t.co/p3DaJCO1Tq— ゆううき (@y_uuk1) 2017年12月2日 2017年のエンジニアリング活動を一言でまとめてみよう。 時系列データベースの開発にはじまり、なぜかIPSJ-ONEで登壇し、その後IPSJ-ONEでの構想をベースにはてなシステム構想を考え始め、ウェブサイエンス研究会でストーリーとしてまとめ上げつつ新たな可能性に気づき、それを実践していく場としてウェブシステムアーキテクチャ(WSA)研究会を立ち上げた。 一方で、仕事では、昨年の振り返りに書いているように、エンジニアとしての専門性を発揮する機会が薄れてきたという問題意識が、いよいよ深刻な課題へと変貌したように感じている。それも残念ながら自分一人だけの問題ではなくなってきた。 この課題をエンジニアリングそのものではなく、人間のスケールアウトでは解決で

    2017年のエンジニアリング振り返り - ゆううきブログ
    tomomii
    tomomii 2018/01/01
    ゆううきさんは一見回り道だぁ大変だーとおもえるステップでもそこで観察したりわかったことを次に繋げてストーリーにしていかれる気がしています
  • TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ

    この記事は第1回ウェブシステムアーキテクチャ(WSA)研究会の予稿です。 cronのようなタイムスケジューラーにより、定期的に実行されるバッチ処理の課題を解決するアーキテクチャを最近考えている。 この記事では、単一のタイムスケジューラによるcronベースの手法に代えて、データに対してタイマーと処理を仕込むことでスケールさせやすい構造にできないか、という提案を試みる。 はじめに Webサービスにおいて、リクエストに対してHTMLのレスポンスを返却する以外のワークロードの多様化が進んでいる。 最近であれば、機械学習による時間周期による大規模なデータ処理が求められることも多い。 その他、月次の課金バッチ処理や、ランキングの定期更新など、一定の時間間隔で任意の処理を実行したいケースは多い。 このような定期的なデータ処理パターンは、SRE[Bet17]の25.1節「パイプラインのデザインパターンの

    TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ
  • ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ

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

    ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ
    tomomii
    tomomii 2017/12/03
    素晴らしいエントリ 製本して手元に置きたい