最近のDHH「サーバーレスをやめろ」 - laiso
(インターネットやめろジェネレーターで作成) Ruby on Rails生みの親であり最強の逆張りおじさんであるところのDHHが昨年あたりからしきりに脱パプリッククラウドの主張をしている。 これは彼らの会社が運用しているBasecampやHEYのインフラをAWSから自社保有のベアメタルサーバーへ移行しようとしているからで、実際に移行作業は進んでおり、今後5年間で700万ドルのサーバー費用を節約できるだろうという見込みがあるようだ。 world.hey.com world.hey.com あとタイトルに「サーバーレスをやめろ」と書いたけどDHHのファンボである筆者の誇張表現であり、サーバーレスというキーワードに関しての言及は正確には以下のポストを読んで欲しい。 world.hey.com この文章における「the computing cycles」とは、一台のコンピュータが持つ計算能力全体を
「エーペックス」の仕組み:開発者によるサーバーとネットコードの解説
これは、とある「エーペックス」のプロプレイヤーのネットワーク経路（レイテンシーを表示しています）です。彼のインターネットモデムから、私たちのサーバーへと到達しています。インターネット接続の本当の状態を判断するため、私たちは何度も調査を行います。最善の状態であれば、彼は31msのレイテンシーでゲームを楽しめていることが見て取れますね。ですが最悪の場合だと、522ms付近です。つまりこの場合だと、接続に500msもの振れ幅があるため、ゲームの遊び心地はかなり悪いということです。彼のローカルISPネットワークの接続は不安定ですが、平均を見てみると非常に稀なケースであることがわかります（平均が31mで、最低値が264ms。たまたま起きたのでしょう）。しかしその後、ローカルのISPとISP1の間でレイテンシーが急増しています。これはプレイヤーとゲームサーバーの間のノードの一つです。この二つの間でパケ
Amazon ECS でのコンテナデプロイの高速化
Amazon ECS でのコンテナデプロイの高速化 この記事は同僚の Nathan Peck (@nathanpeck)が書いた記事 “Speeding up Amazon ECS container deployments” を翻訳し、加筆・修正したものです. 元記事を ECS ユーザに紹介する機会が何回かあったので、せっかくなので翻訳することにしました. コンテナのオーケストレーションは非常に複雑な問題の一つです. アプリケーションコンテナのデプロイのために、相互にやり取りを行う複数の異なるコンポーネントが存在します. あなたのアプリケーションを実行したオーケストレータは、その実行されたアプリケーションが Web トラフィックを受け取る用意ができているかどうかについて判断する必要があります. その後そのアプリケーションはスケールダウンされたり、あるいは新しいバージョンのアプリケーション
fluentdでつくる監視系 - Qiita
いつもアプリケーションの開発ばかりで、まじめに監視系を考えたことがなかったので、 fluentdを中心にした監視系を作ってみた。 前提 複数台のアプリケーションサーバ 一台のログ収集サーバ ログにはエラーログとアクセスログの大きく2種類を用意する エラーログは更に複数のレベルでファイル単位にわかれている fatal error warn アプリケーションサーバとログ収集サーバは同一ネットワーク上にある やりたいこと メールで来ても絶対に気がつかない自信がある。 異常の側から教えてくれる仕組みを目指す。 fatalログが出た場合は、電話による通知を行う 全てのエラーログはchatツールに出力する ログのバックアップ ログの分析・可視化 この記事では1, 2, 3についてまとめる。 構築 fluentdのインストール 公式のドキュメントが一番わかり易い。 Installation | Flue
ファーストサーバ最終報告書、ベテラン担当者のマニュアル無視を黙認
ヤフー子会社のファーストサーバは2012年7月31日、6月20日に発生した大規模障害（関連記事）についての調査報告書（最終報告書）を公表した（写真）。報告書は、ファーストサーバに利害関係のない3人の委員による「第三者調査委員会」（関連記事）が作成した。同社Webサイトに「要約版」を掲載している。 報告書は調査対象とする事故を、6月20日に発生した「第1事故」と、第1事故で消失したデータが想定外の場所に復元された「第2事故」（関連記事）の2つとしている。 1人だけ自作プログラムでメンテナンス 報告書は、第1事故の事実関係について次のように言及している。ファーストサーバではシステム変更を実行する際、社内マニュアルに沿って実行することになっており、第1事故の原因となったシステム変更の担当者（A氏）以外は社内マニュアルに従っていた。 ところが、A氏だけはマニュアルに従わず、自作の「更新プログラム」
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「一線」を越えた自宅サーバー管理者のあなたへ。よく使うルーターやサーバーを集めたダッシュボードを「Dashy」で作る【イニシャルB】
