第4回 WSA 研究会に参加した
開催概要: https://websystemarchitecture.hatenablog.jp/entry/2019/02/26/100725 自分の発表とくに手持ちの実装や実装構想といったものがなかったため、最近よく考えていたカオスエンジニアリングについての整理を試みた。Netflix による “Chaos Engineering” ペーパーでは、すでにカオスエンジニアリングと同じようなことを Google や Amazon といった企業はすでにやっていることを知っていてそれをカオスエンジニアリングと名付けたと書いてある。その起源は明らかに「レジリエンス」のキーワードに関係していて、レジリエンスエンジニアリングという体系化された学問があることを知った。 レジリエンスエンジニアリングを調べてみると、最近の Web サービスにおける信頼性の考え方、SRE のエッセンスの一部が Safet
TCP接続の追跡による簡略化したネットワーク依存関係グラフの可視化基盤 - ゆううきブログ
著者: 坪内佑樹(*1), 古川雅大(*1) 所属: (*1) 株式会社はてな 研究会: Web System Architecture研究会#3 はじめに ウェブシステムは，一般的に，分散したホスト上で動作するソフトウェアが互いにネットワーク通信することにより構成される． 相互にネットワーク通信するシステムにおいて，システム管理者があるネットワーク内のノードに変更を加えた結果，ノードと通信している他のノードに変更の影響がでることがある． ネットワーク接続数が多いまたはノードが提供するサービスの種類が多くなるほど，システム管理者が個々の通信の依存関係を記憶することは難しくなる． さらに，常時接続しておらず必要なタイミングで一時的に通信するケースでは，あるタイミングの通信状況を記録するだけでは通信の依存関係を把握できない． その結果，システムを変更するときの影響範囲がわからず，変更のたびに依
ミドルウェア実行環境の多様化を考慮したインフラアーキテクチャの一検討 - masayoshiの日記
このエントリは第2回Web System Architecture研究会の予稿です． 発表資料 speakerdeck.com はじめに Webサービスのインフラを設計する上で、RDBやWebサーバを始めとした多くのミドルウェアは欠かせないコンポーネントの一つであり、それらの構築、運用も重要な要素である。 LAMP環境が提唱された1998年頃とは異なり、同じことを実現できるミドルウェアが複数あり、Webサービス開発者はミドルウェアの選択肢の幅が広がった。 また、2005年以降、サーバ仮想化技術の普及を始めに、クラウドベンダーによるミドルウェアのフルマネージドサービスやコンテナ技術の登場により、ミドルウェアの実行環境は多様化してきた。 同一のミドルウェアでも、実行環境が変わることにより、構築、運用手法や利用可能なツールが異なることがあり、それらの違いを表現可能なアーキテクチャの議論は十分にさ
Sanny: 大規模ECサイトのための精度と速度を両立した分散可能な近似近傍探索エンジン
このエントリは、第二回 Web System Architecture 研究会 (WSA研)の予稿です。 はじめに ECサイトの商品種類増大に伴う情報過多問題を解決するため，利用者の要求を満たす商品を自動的に提案する機能がECサイトにとっての関心事となる．商品の提案は任意の観点での商品同士の類似性を根拠とすることから，商品の特性を数値化し，任意の距離空間で近傍に位置する要素を求めることで，機械的に扱えるようにする．この数値化された商品特性を特徴量と呼ぶ． 深層ニューラルネットワークの発展によって，これまで適切な特徴量を導くことが難しかった画像やテキストに対しても，人の感性に近い，特性をよく表現する高精度な特徴量を得られるようになったことからECサイトの商品提案機能に利用され始めている． これらの深層ニューラルネットワークから得られる特徴量は，数百から数千次元の高次元ベクトルとして表現される
第2回Web System Architecture研究会＠福岡 に参加した #wsa研 - Copy/Cut/Paste/Hatena
まさに「Webシステムのアーキテクチャ」で悩んでいることがあって、どうしても「これだ！」という情報を探すことができなかったところ、Web System Architecture研究会が福岡で開催されるということで渡りに船とばかりに参加してきました。 発表内容 予稿 github.com 発表資料 発表した内容を端的に説明すると「Webシステム前提において、トラブルシュートのために生ログにアクセスするためのログ保存の方法として、パス構造にリクエスト-レスポンスの伝搬情報を埋め込んだらどうだろう？」という提案でした。 参加して発表してみて 感想は、以下のツイートに集約されています。 #wsa研 お疲れ様でした！発表することで知見を得たいという目論見は、想像以上の結果を得ることになりました。 いろいろ収穫はありましたが、その中でもhayabusaというログ基盤とそのアイデアの根幹をまさかのその作
第2回Web System Architecture研究会＠福岡 #wsa研 を開催します - Web System Architecture 研究会 (WSA研)
第1回で非常に好評だったWeb System Architecture研究会の第2回を福岡で開催します！ websystemarchitecture.hatenablog.jp ぜひぜひ皆様ご応募、ご参加下さい。 いわゆるWebでも、情報ネットワークでもなく、Webを中心とした様々な技術要素および要素のつながりを含む系全体のアーキテクチャを議論をします。 websystemarchitecture.hatenablog.jp 日時と場所 日時: 2018年5月12日(土) 10:00~19:30 その後 懇親会 場所: ペパボ福岡オフィス7F ペパステ 発表形式 参加者全員発表形式です 12人発表で、当日の発表は3人×30分セッションを4セッションで、10:30~12:00 13:30~15:00 15:30~17:00 17:30~19:00 パターンを想定しています 参加希望者は tw
第1回WSA研究会に参加してみた振り返り - ブログ・ア・ラ・クレーム
あけましておめでとうございます。年末年始はほぼ寝て過ごしていました。 表題の通り、去年に 第1回WSA研究会 というイベントに参加したのでその振り返りなどをさくっと書いていきます。 第1回WSA研究会全体への雑感 発表内容は以下の通りで、名前の通り Web System Architecture の体系化や選定、流行りの Microservices 、ストレージに関する内容が多かった印象です。 websystemarchitecture.hatenablog.jp イベント中ははてなさんの会議室の一角を利用して割と近い距離感のなか発表者が事前準備したスライドと共に発表し、聴衆が様々なコメントをしていく形式です。 発表時間15分,質疑応答15分というスケジュールのなか、発表自体も質疑もなかなかの盛り上がりをみせ、充実した時間になったのではないかと感じます。 このイベントで個人的に興味深かった
2017年を振り返る - Man page of CHIKU_WAIT(2)
気がついたら2017年もあと数日で終わってしまうので、今年1年をひたすら振り替えてってみようと思います。今年も濃かったなあ。 しんどい時期（1〜3月） 元々学習欲・知識欲からプログラミングをやっていたので、特に作りたいものがあるわけではなかった。同級生や先輩がスマホのアプリとかWEBアプリとかで作りたいものをガンガン作っていくのが羨ましかった。周りは「こんなものが作りたい」と学んで成果物を作っていく中、自分は知識欲で漠然と本にあるサンプルを写経して満足して次の本を写経するということをしていた。 知識欲や学習欲は満たされていくけど、周りとのギャップが正直苦しかった。また僕が居る大学は何かモノを生み出していくことが強く、雰囲気的にも成果物を生み出すことが強さであるみたいな雰囲気があった(個人的な感想)。こういう大学で触っているのが好きで学習欲や知識欲からプログラミングしているっていうのが周りと
Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究課題についての整理と考察 - masayoshiの日記
第1回WSA研究会 開催概要 - Web System Architecture 研究会 (WSA研)で発表したときの予稿になります。 今回はWSA研の第一回ということもあり、自分自身で何をしたいのかという点を整理するための発表という形になりました。 まだ、整理や調査が不十分である状態ではありますが、WSA研のような場所で現状できているところまでを報告し、色々議論できたことでよりより調査を行えるかなと思っています。 このように、明確な成果でなくても発表し議論できるところがWSA研のいいところかなと思っている*1ので、興味ある人はぜひ参加を検討してみてください。 発表資料 speakerdeck.com 研究テーマ Webサービスにおけるインフラアーキテクチャの体系化とインフラアーキテクチャの選択自動化の研究 研究背景 Webサービスに求められるユーザ要求は，高度かつ激しく変化する． それに
分散アプリケーションにおける複数端末利用を考慮したプライベートデータの管理
このエントリは、第一回 Web System Architecture 研究会 (WSA研)の予稿です。 1. はじめに ブロックチェーン技術の登場により、インターネットを経由した個人間での直接の価値交換が容易となりつつある。 これまで、インターネット上での個人間での価値交換の場を提供してきた、マーケットプレイス型のECサイトや、シェアリングエコノミーの代表である、AirbnbやUberは、一旦情報を集約し提供する仲介者としてのビジネスを行ってきた。これらのビジネスはニーズのマッチングと取引の信頼性の提供の二つの側面で価値を提供している。一方、ブロックチェーンは、非中央集権的な台帳管理をトランザクションの順序性を明確にするデータ構造とブロック生成と検証に系が正しく回るような仕組みを組み込むことで、信頼性の提供を実現する。このように中央集権的な存在を介さないブロックチェーン上で動作するBit
実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャと今後の課題 - 人間とウェブの未来
一年前にFastContainer構想という記事を書いてから、主にアカデミアでFastContainerに関する研究をすすめたり、FastContainerに基いて実装されている「ロリポップ！マネージドクラウド」というロリポップ！の新しいプランのリリースに向けて取り組みを行ったりしておりました。 hb.matsumoto-r.jp そこで、ブログでも「FastContainer: 実行環境の変化に素早く適応できる 恒常性を持つシステムアーキテクチャ」についての構想からのアップデートをまとめておきたいと思います。 英文タイトルは、 A Homeostatic System Architecture Rapidly Adapting Execution Environment Changes です。 はじめに 背景 目的 提案の概要 Serverlessアーキテクチャによる実装との違い Her
TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ
この記事は第1回ウェブシステムアーキテクチャ(WSA)研究会の予稿です。 cronのようなタイムスケジューラーにより、定期的に実行されるバッチ処理の課題を解決するアーキテクチャを最近考えている。 この記事では、単一のタイムスケジューラによるcronベースの手法に代えて、データに対してタイマーと処理を仕込むことでスケールさせやすい構造にできないか、という提案を試みる。 はじめに Webサービスにおいて、リクエストに対してHTMLのレスポンスを返却する以外のワークロードの多様化が進んでいる。 最近であれば、機械学習による時間周期による大規模なデータ処理が求められることも多い。 その他、月次の課金バッチ処理や、ランキングの定期更新など、一定の時間間隔で任意の処理を実行したいケースは多い。 このような定期的なデータ処理パターンは、SRE本[Bet17]の25.1節「パイプラインのデザインパターンの
第1回 WSA 研究会に参加した
開催概要: http://websystemarchitecture.hatenablog.jp/entry/2017/12/17/133301 きっかけ元々のきっかけは、僕が酔っ払って適当にツイートしてたら、y_uukiさんにいい感じにされてた [Twitter] ことである。y_uuki さんとは一度リモートで会ったことがあったので、じゃあ物理で会いに行こうということになっていた。それとは別に、もともと WSA 研には興味があった。その理由は主に次の2つである。 Web サービスインフラの寿命最近は Web サービスインフラの可能性について漠然と考えていた。近年、AWS, GCP をはじめとするクラウド、IaaS でサービスを構築することは当たり前になっている。そして、Heroku をはじめとする PaaS, さらには CaaS (Container as a Service) もある
Web System Architecture研究会の発足と挨拶
id:masayoshiです． この度，Web System Architecture研究会(WSA研)を発足いたしました． 発足の経緯はid:matsumoto_rさんとid:y_uukiさんと「ペパボ・はてな技術大会〜インフラ技術基盤〜@福岡」という勉強会で会話した際に，私が「この分野で一つの研究分野，学問としてもっと盛り上がるといいのになぁ」という(ような)発言をしたのがきっかけだったと思います． 私自身はアウトプットも苦手でコミュニティ運営などしたこともないのですが，言い出しっぺの法則で研究会主査となりました． とりあえず，今年中に第一回をやるかということになったので，とりあえず形式を決めgistで出してやり方を模索しながらやっていこうと思っていたら，さっくり10人以上集まってしまったのでびっくりしているところです． 第一回は発表者は5~6人程度を考えていたので，ひとまず今回の発表
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Where Chaos Engineering comes from, and what's next
WSA研 第1回に参加してきた