タグ

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

  • ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ

    ISUCONに参加する会社の同僚を応援するために、ISUCONの予選突破する上で必要なオペレーション技術を紹介します。 自分がISUCONに初出場したときに知りたかったことを意識して書いてみました。 一応、過去2回予選突破した経験があるので、それなりには参考になると思います。 といっても、中身は至って標準的な内容です。 特に、チームにオペレーションエンジニアがいない場合、役に立つと思います。 今年のISUCON6は開催間近で、まだ予選登録受付中です。 ※ 文中の設定ファイルなどはバージョンやその他の環境が異なると動かなかったりするので必ず検証してから使用してください。 ISUCONでやること (Goal) ISUCONでやることは、与えられたウェブアプリケーションをとにかく高速化することだけです。 高速化と一口に言っても、複数のゴールがあります。ウェブアプリケーションの場合は以下のようなも

    ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ
    Jxck
    Jxck 2016/08/23
    あとで読む
  • 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ディストリをライブアップグレードした話 - ゆううきブログ
    Jxck
    Jxck 2016/06/01
    Google も Red hat 使ってたんだ
  • 自作Linuxコンテナの時代 - ゆううきブログ

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

    自作Linuxコンテナの時代 - ゆううきブログ
    Jxck
    Jxck 2016/04/28
  • 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を組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
    Jxck
    Jxck 2015/12/01
  • はてなで大規模サービスのインフラを学んだ - ゆううきブログ

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

    はてなで大規模サービスのインフラを学んだ - ゆううきブログ
  • Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ

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

    Webシステムにおけるデータベース接続アーキテクチャ概論 - ゆううきブログ
  • 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サーバアーキテクチャ序論 - ゆううきブログ
    Jxck
    Jxck 2015/05/28
    すごく良くまとまってる。
  • Mackerelを支える時系列データベース技術 - ゆううきブログ

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

    Mackerelを支える時系列データベース技術 - ゆううきブログ
  • Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ

    記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を

    Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
    Jxck
    Jxck 2015/03/31
    RSS は知ってたけど、 RPS は知らなかった。 NIC が対応してなくてもできるんのか。
  • #Gokyoto - ゆううきブログ

    Go勉強会 そうだ京都、行こう on Zusaar Gokyoto 行ってきた。 Go、チュートリアルやったり、Docker のコード読んだりくらいしかしてなかったので、集中して Go 勉強できるちょうどいい機会だった。 A Tour of GoGo に入門した - ゆううきブログ Go @Jxck_ さんの当日の資料、コンパクトにまとまっててよかった。 A Tour of Go さっとみたあとにみるとよい感じする。 Go Kyoto(Go勉強会 そうだ京都、行こう) のハンズオン資料 (http://www.zusaar.com/event/4367004) 新しい言語を覚えようとすると、言語仕様はもちろんある程度覚える必要があるけど、開発補助ツールとか標準的な書き方とかデバッグ方法とか実装に向いたアプリケーションの性質などの文化を知る必要がある。 Perl とか歴史が長い言語ほど

    #Gokyoto - ゆううきブログ
    Jxck
    Jxck 2014/03/16
    ありがとうございました! #gokyoto
  • 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コネクションをひとつにまとめるとはどういうことか -

    HTTP/2.0と今後のWebアプリケーションの開発・運用について (#cross2014) - ゆううきブログ
  • Chefがつらい人のためのAnsibleのはなし - ゆううきブログ

    Chef使おうとしてるけどChefいろいろつらい. 具体的には以下がつらい. 独自概念多い chefのクライアントを対象ホストに入れなければならない knifeとか覚えないといけない外部ツールがある 最初からディレクトリ構成がわいわい (rails newしたときのあのきもち) 公式ドキュメントの量が多いかつわかりにくい 以前にmiyagawaさんのpodcast を聞いてたらnaoyaさんがAnsibleっていうシンプルなプロヴィショニングツールがあるっていう話をされていたので,使ってみた. AnsibleWorks | Radically simple IT orchestration Ansible 触ってて感じるイメージは,ChefがRailsでAnsibleがSinatraな感じ. ディレクトリ構成がない (一応大規模運用を考えたディレクトリ構成のベストプラクティス Best P

    Chefがつらい人のためのAnsibleのはなし - ゆううきブログ
    Jxck
    Jxck 2013/08/14
    自分にはこっちでいい気がしてきてる。試すかなぁ。
  • SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ

    SPDYが流行っていて,複数のTCPコネクションを1つにまとめて高速化を図るらしいということは知っていた. しかし,単にTCPのコネクション数を抑えるだけならHTTP 1.1のKeep Aliveやpipeliningを使えばよいし,既存技術のどこが問題でSPDYはどう解決しているのかを調べてみた. SPDYの人でもWeb標準の人でもなんでもないので,間違いが多分含まれています. 並列TCPコネクション 並列にTCPコネクションを張る状況として,Webの世界においては以下の2つを思いつく. ブラウザがあるページをロードして,そのページに複数の画像ファイルが含まれており,それらを同時に取得するために並列にTCPコネクションを張り,HTTPリクエストを投げる. JSで非同期に複数のHTTPリクエストを投げる.1個のリクエストを投げるときに1個のTCPコネクションを張る. 並列TCPコネクション

    SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ
    Jxck
    Jxck 2013/03/09
    良記事。ただ最後の 「TCP の上で TCP」はどっちかというと WebSocket かなぁ。
  • 1