タグ

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

  • サーバーレスアーキテクチャ再考 - ゆううきブログ

    2014年にAWS Lambdaが登場し、Functionを単位としてアプリケーションを実行する基盤をFunction as a Service(以下、FaaS)と呼ぶようになった。 そして、同時にサーバーレスアーキテクチャ、またはサーバーレスコンピューティングと呼ばれる新しいコンセプトが普及するに至った。 当初、そのコンセプトが一体何を示すかが定まっていなかったために議論が巻き起こり、今現在では一定の理解に着地し、議論が落ち着いているようにみえる。 しかし、サーバーレスという名付けが悪いということで議論が着地したようにみえていることにわずかに疑問を覚えたために、2019年の今、これらの流れを振り返ってみて、サーバーレスアーキテクチャとは何かを改めて考えてみる。 サーバーレスとの個人的関わり サーバーレスアーキテクチャという名を僕がはじめて耳にしたのはAWS Lambdaが登場した2015

    サーバーレスアーキテクチャ再考 - ゆううきブログ
  • 株式会社はてなを退職しました - ゆううきブログ

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

    株式会社はてなを退職しました - ゆううきブログ
  • コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ

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

    コスト効率の悪いLambdaアプリケーションの性質に関する考察 - ゆううきブログ
    ikosin
    ikosin 2017/11/06
    EC2 の最小課金が60秒からになって使い方の幅が広がってるので、情報をアップデートしないとなと思ってる
  • RedisサーバのCPU負荷対策パターン - ゆううきブログ

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

    RedisサーバのCPU負荷対策パターン - ゆううきブログ
  • 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ

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

    時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ
  • ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ

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

    ISUCON予選突破を支えたオペレーション技術 - ゆううきブログ
  • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

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

    ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
    ikosin
    ikosin 2016/03/03
    新言語どうこう関係なくても、ちゃんとWebアプリを動かすための周辺知識の教材としてもよくカバーできてると思う
  • Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ

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

    Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
  • 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を組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
  • YAPC::Asia 2015で技術ブログを書くことについて発表しました - ゆううきブログ

    YAPC::Asia Tokyo 2015の前夜祭で上記のタイトルで発表しました。 今回が最後のYAPCということで、どのようなテーマで応募するかについてかなり悩みました。 技術的にめぼしい内容はほとんどブログに書いてしまったので、ブログを書くことそのものについて発表してみようと思いました。 内容についても、トークの話の元となる個々の要素についてはほとんど固まっていたものの、どのように構成して取捨選択するかということに時間を使いました。 基的に難しい話はないので、スライドには極力文字を載せずに口頭の話を聴いていただくという形をとりました。 したがって、スライドだけみても情報量がほとんどなく何の話か全然わからないので、公開はしないでおこうと思います。 トーク内容 トークの内容は前半部分と後半部分に分かれています。 前半は基的に来ていただいた方々に楽しんでいただくように構成して、トークの主

    YAPC::Asia 2015で技術ブログを書くことについて発表しました - ゆううきブログ
  • CentOS 5.9でNICを2枚挿したときのネットワーク設定 - ゆううきブログ

    10GbpsNIC環境でOSのネットワークスタックのパフォーマンスを測定しようとしたら意外と面倒だった.厳密には,面倒だったのはCentOS 6系での設定で結局あきらめた. 仕方がないからCentOS 5.9でやるとそれほどハマらずに設定できた. 2台のマシンがあり,オンボードNICと10GbpsNICが載っている.このとき, 10GbpsNIC同士を直接10Gbps Eternetで接続する. オンボードNICはゲートウェイを通してインターネットに接続できるようにする. というのが課題. これに対して以下の図のようなネットワーク構成にしたらちゃんと通信できた. 設定 大雑把な設定内容を以下のような感じ. オンボードNIC周りと10GbpsNIC周りを異なるサブネットに置く. インターネットに接続するために192.168.1.1をデフォルトゲートウェイとする. 10.0.0.1を10.0.

    CentOS 5.9でNICを2枚挿したときのネットワーク設定 - ゆううきブログ
  • パフォーマンスの観点からみるDockerの仕組みと性能検証 - ゆううきブログ

    Docker Meetup Tokyo #4 にて「Docker Performance on Web Application」という題で発表しました。 発表内容は、下記の2つの記事をまとめたものに加えて、最新バージョンの Docker 1.4 での ISUCON ベンチマークと、storage-driver として Device Mapper + Docker 1.4 から実装された OverlayFS を試しました。 Dockerは速いのか?Dockerのパフォーマンスについて重要なことは何か? - ゆううきブログ ISUCONでNginxMySQLDocker化したときのパフォーマンス - ゆううきブログ この記事は、上記2記事で、いくつか難しいポイントがあったとフィードバックをいただいたので、Docker Meetup での発表内容を少し詳しめに説明したものになります。 1.

    パフォーマンスの観点からみるDockerの仕組みと性能検証 - ゆううきブログ
  • 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サーバアーキテクチャ序論 - ゆううきブログ
  • Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ

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

    Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
  • 2014年、技術しかしてない - ゆううきブログ

    2014年、振り返ってみてもとにかく技術しかしてない。 Webオペレーションエンジニアになった。 1人でサービスを構築・運用するようになった。 とうとう25歳になった。もう定年だ。 9月に引っ越した。自炊あきらめた。 ISUCON4の戦で惨敗した。Cache-Controlとか知らんし。 ブログで承認ゲットした。 Dockerしてた。Dockerは最高。 数編の論文を読んた。 京都在住にしてはとにかくたくさん技術プレゼンした。東京で消耗してた。 新卒入社成功してから1年がたってた。 入社1年成功 https://t.co/HA3k3n76kC— yuuki (@y_uuk1) December 1, 2014 去年の目標みたいなのを振り返ってみる。 2013年をとにかく忘年したい - ゆううきブログ プロとしてのエンジニアリングをやっていく なにがプロだ。 ブログエントリばかり読んでない

    2014年、技術しかしてない - ゆううきブログ
  • Perlはもう古い、これからはDocker - ゆううきブログ

    記事の内容はWEB+DB Vol.88 Perl Hackers Hub 第34回 に「DockerによるPerlのWebアプリケーション開発」という記事にまとめなおしていますのでそちらをご覧ください。 「Perl Hackers Hub」では、「DockerによるPerlのWebアプリケーション開発」と題して@y_uuk1さんにご執筆いただきました!Dockerの基的な考え方からPerlのWebアプリ向けのDockerfileの書き方まで、実践的な内容です! #wdpress— WEB+DB PRESS編集部 (@wdpress) 2015, 8月 22 この記事は Perl Advent Calendar 2014 の19日目の記事です。 Plack/Carton で構築したモダンな Perl の Web アプリケーションの開発環境を Docker 化するための試行錯誤を紹介します

    Perlはもう古い、これからはDocker - ゆううきブログ
  • 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を用いたジョブキューシステムを作るときに考えたこと - ゆううきブログ
  • 東京はもう古い、これからは京都 - ゆううきブログ

    https://twitter.com/hotchemi/status/493599957438308352 最近、京都市内に引っ越して生活クオリティがあがってる。家はオフィスのある烏丸御池からちょっと離れたところの、閑散としたところにある。 自炊活動を全て捨てていて、調理器具はおろか電子レンジもないし、お皿も箸もスプーンもない。 代わりに、隠れ家っぽいお店に行くのが好きなので、毎日いろんな店に行ってる。 そんなに高い店には行かないので、費は思ったほどかかってない。 先週の休みは、昼過ぎに起きて、御所の近くまで散歩して、隠れ家っぽいカレーショップでさつまいもチキンカレーべて、コンテッサチェアを観るために家具の店行って、隠れ家っぽいケーキ屋でアーモンドケーキとプリン買って帰って、部屋でプリン爆発させたりした。 コンテッサチェアについては以下のエントリが詳しい。 プリン、まれに爆発するので

    東京はもう古い、これからは京都 - ゆううきブログ
    ikosin
    ikosin 2014/11/26
    京都市内に住みたかった
  • ISUCONでNginxとMySQLをDocker化したときのパフォーマンス - ゆううきブログ

    現実的なWebサービス環境において、Docker化によるパフォーマンス低下がどの程度のものか調査するために、 ISUCON4 の予選問題のうち、NginxMySQL 部分を Docker 化してベンチマークをとってみた。 典型的なWebサービスシステムの3層構造(Proxy, App, DB)を構築し、ベンチマーカーにより高ワークロードを実現できるので、ISUCON の予選問題は適当な題材といえる。 Docker のパフォーマンスについて留意することは先日書いたエントリに全て書いてる。 上記のエントリを要約すると、Docker のパフォーマンスについて重要なこととは storage-driver の選択 (AUFS or Device mapper or ...) Volume の ON / OFF AUFS などの差分ファイルシステムをバイパスするかしないか Host networ

    ISUCONでNginxとMySQLをDocker化したときのパフォーマンス - ゆううきブログ