スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術 - MonotaRO Tech Blog
どんなことが起こったのか？ モノタロウのサイトの監視について レイテンシ監視 トラフィック監視 エラー監視 リソース監視 ログ トラブルシュートの進め方 発生検知 発生箇所の特定 根本原因の調査 強化 課題 おわりに SREチームの市原(@ichi_taro3) です。 モノタロウでは、www.monotaro.com という大規模なECサイトを自社で開発、運用しています。 Webアプリケーションの運用ではトラブルはつきものです。今回は、とあるトラブルシュート事例を軸に、どのように運用を改善しているのかについて紹介します。 どんなことが起こったのか？ あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウトの増加が頻発したことがありました。 当然これらは歓迎される状況ではなく、すぐに開発者やSRE、インフラチームの担当者が集まり調査を開始しました。現象は
インフラのボトルネックについて知る - ぺい
インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基本的な考え CPU使用率が80％から90%をずっと推移している！と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ
IPMI の概要
Intelligent Platform Management Interface (IPMI) は、標準化されたメッセージ・ベースのハードウェア管理インターフェースです。IPMI の中核には、ベースボード管理コントローラー (BMC) または管理コントローラー (MC) と呼ばれるハードウェア・チップがあります。 BMC は、システム・ハードウェアのヘルスをモニターするために必要な各種のインターフェースを提供します。ユーザー・チャネル用、要素 (温度、電圧、ファン速度、バス・エラー、その他の要素) のモニター用、手動によるリカバリー (ローカルまたはリモートのシステムのリセットや電源のオン/オフ操作) 用、および異常状態または「範囲外」状態の場合の、将来の検査とアラートのためのオペレーティング・システムによる介入を伴わないログイン用に、さまざまなインターフェースが存在します。 注: BM
オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか？ その舞台裏と今後の展望 | フルスイング by DeNA
今後のモノづくりには「インフラ・セキュリティ・品質管理がより一層ビジネスに踏み込んだ動きを取ることが重要になってくる」と考えるDeNA執行役員システム本部長のnekokakこと、小林 篤（こばやし あつし）。 そんなnekokakがDeNAのシステム本部各部長と「各領域からビジネスに踏みこむモノづくり」について語り合う『モノづくり対談』第2回目をお送りします。 テーマは「オンプレミスに強みを持つDeNAはなぜクラウド化全面移行を決めたのか」。 オンプレの品質コスト世界一を自負するDeNAに、全面クラウド化というドラスティックな意思決定をもたらしたIT基盤部部長・金子 俊一（かねこ しゅんいち）とプロジェクトの全貌を語り合いました。 「クラウド全面移行を決めた理由」「コストの大幅増への対処法」「経営層の意思決定に担当者工数などの課題」など、気になるクラウド化の裏側を解き明かします！ ※この記
Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」正式発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 － Publickey
Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」リリースを発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 SpinnakerはもともとNetflixが開発し、2015年にオープンソースとして最初のバージョンを公開しています。 参考：Netflix、マルチクラウド対応の継続的デリバリを実現する「Spinnaker」をオープンソースで公開 このときすでにNetflixの開発にGoogleは参加しており、その後もSpinnakerの開発が進められてきました。 Spinnakerはデプロイに求められるほとんどすべての機能を備えていると、次のように説明されています。 In Spinnaker, deployments are orchestrated using custom release pipelines,
ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
この文章は、サーバサイドのウェブアプリケーション開発において、社内実績の少ない新しい言語を採用したときにインフラ面で考慮したことを社内向けにまとめたものです。 はてなでは、長らくPerlでウェブアプリケーション開発を続けてきた一方、ここ数年で社内でScalaまたはGoの採用事例も増えてきました。 今後開発が始まるプロダクトにおいても、Perl、Scala、Goもしくは他の言語を採用するかどうかを開発開始時に選ぶことになるでしょう。 新言語を採用するときに、考慮すべきことの一つとして、「インフラ」への影響があります。 新言語に関する雑談をしていると、ウェブアプリケーションエンジニアに「インフラ」への影響について聞かれます。 もしくは、ウェブオペレーションエンジニアから考慮するポイントを伝えることもあります。 ScalaやGo以外に、Node.jsやサーバサイドSwiftはどうかというのも雑談
Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
AWSのリソース構成をServerspecのようにテストする "awspec" をつくった - Copy/Cut/Paste/Hatena
AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon
20150419_pbtech_openstack_nyah #pbtech
#pbtech 第1回ペパボテックカンファレンス http://pepabo.connpass.com/event/13208/
Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効
Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Consul は 全自動オーケストレーションの 夢を見るか?
Raft