aki77のブックマーク - はてなブックマーク

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

aki77 2015/07/30

リンク

はてなで大規模サービスのインフラを学んだ - ゆううきブログ

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

aki77 2015/07/30

リンク

Mackerelを支える時系列データベース技術 - ゆううきブログ

【追記 2018/01/06】現在Mackerelは、時系列データベースという概念をクラウドの技で再構築する - ゆううきブログの時系列データベース実装へ移行しています。サーバモニタリングサービス Mackerel で採用している時系列データベース Graphite を用いたシステムの構築と運用事情を紹介します。Graphiteについては、プロビジョニングやアプリケーションからの使い方、Graphite自体のモニタリングなど様々なトピックがありますが、特に大規模ならではのトピックとして、Graphiteの内部アーキテクチャ、パフォーマンスチューニングおよびクラスタ構成についての知見を書きます。背景 Graphiteシステム概観データ構造とアーキテクチャ whisperのデータ構造 carbon-cacheのアーキテクチャパフォーマンス特性パフォーマンスチューニングミドルウェアレ

aki77 2015/04/30

リンク

DockerとS3を用いた、yum / apt リポジトリ作成・運用の継続的インテグレーション - ゆううきブログ

Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログの続き。前回は、rpm / deb パッケージを作るために、CentOS、Debianなど各種ディストリビューションを揃える手間をかけずに、Docker コンテナ上でパッケージングして、ついでに Jenkins で CI するみたいなことを書いた。今回は、作成したパッケージを yum / apt リポジトリに登録して yum / apt コマンドでパッケージインストール/アップデートできるようになるまで継続的インテグレーションするという話。問題点 yum / apt リポジトリ用の専用ホストを立てて、そこで apache とかで静的ファイルをホストするのはめんどくさい。特に、mackerel-agent みたいなユーザにインストールしてもらうパッケージの場合、リポジトリを公開し

aki77 2014/05/28

リンク

Docker を用いた rpm / deb パッケージ作成の継続的インテグレーション - ゆううきブログ

サーバ管理ツールのエージェントみたいなソフトウェアをインストールしやすくするために、rpm / deb パッケージを作りたい。しかし、rpm / deb パッケージ化するためには、それぞれ CentOS(RedHat)、Debian(Ubuntu) 環境でパッケージ化することになる。社内ではこれまでパッケージ化の専用ホストがいて、そこで spec ファイルや init スクリプトを置いて rpm build コマンドとか debuild コマンドを叩いてパッケージを作成していた。さらに、アプリケーションエンジニアからインフラエンジニアに依頼するという形をとっていた。この方法の問題点として、以下の3つがある。 spec ファイルや init スクリプトなどをプロジェクトの Git リポジトリで管理しづらい。つまり、レビューとかがやりにくい。リリースフローを自動化しづらい。具体的には

aki77 2014/05/12

rpm
docker

リンク

HTTP/2.0と今後のWebアプリケーションの開発・運用について (#cross2014) - ゆううきブログ

追記 @jovi0608 さんに非常に丁寧にコメントをいただきました。 https://gist.github.com/shigeki/ba7941d114344ddd4b01 本文 CROSS 2014の次世代Webセッションに参加した。いろいろ刺激を受けたので、特に、Webアプリケーションを開発・運用する上で、今後どう影響してくるだろうみたいな視点で整理したことを書いてみた。次世代Webセッションは去年もUSTで見てて、めっちゃ面白かったので、今年は生で聞きに来た。去年のセッションの議論は、 naoyaさんの記事が雰囲気がわかりやすかった。 Webはインターネットになった - naoyaのはてなダイアリー去年、SPDYの内容とか追ってて、HTTP/1.1と何が違うのかみたいなことを調べて書いたりしてた。 SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか -