タグ

infrastructureに関するkarupaneruraのブックマーク (13)

  • スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術 - MonotaRO Tech Blog

    どんなことが起こったのか? モノタロウのサイトの監視について レイテンシ監視 トラフィック監視 エラー監視 リソース監視 ログ トラブルシュートの進め方 発生検知 発生箇所の特定 根原因の調査 強化 課題 おわりに SREチームの市原(@ichi_taro3) です。 モノタロウでは、www.monotaro.com という大規模なECサイトを自社で開発、運用しています。 Webアプリケーションの運用ではトラブルはつきものです。今回は、とあるトラブルシュート事例を軸に、どのように運用を改善しているのかについて紹介します。 どんなことが起こったのか? あるとき、モノタロウのWebサービス全体でレイテンシ悪化やバックエンドAPIへのタイムアウトの増加が頻発したことがありました。 当然これらは歓迎される状況ではなく、すぐに開発者やSRE、インフラチームの担当者が集まり調査を開始しました。現象は

    スケールアウトの落とし穴から学ぶ、SREチームでのダッシュボードのアップデート術 - MonotaRO Tech Blog
  • インフラのボトルネックについて知る - ぺい

    インフラのボトルネックを理解する コードはもちろん、リリースしてから安定して動かせるように面倒を見るまでが仕事というのが、弊社の開発スタイルなので、そこで最近学んだことについて、文献や自分の実体験からボトルネックに関する考え方をまとめてみた。 CPUボトルネック CPU使用率に対する基的な考え CPU使用率が80%から90%をずっと推移している!と聞くと、自分のPCの感覚だと、「やばそう」という感覚に陥りますが、インフラにおいての使用率はそうとも限りません。 CPU使用率高い: うまくリソースを使い切っている CPU使用率低い: オーバースペック ただ、高いCPU使用率にも許容出来る度合いがあったりもするので、そこらへんの判断軸などを踏まえて、まとめてみる。 現実世界の例 CPU使用率が高い状態というのは、実世界に置き換えると、店員がみな忙しく働いているという状態です。利用者からすればオ

    インフラのボトルネックについて知る - ぺい
    karupanerura
    karupanerura 2019/10/31
    良記事だった
  • IPMI の概要

    Intelligent Platform Management Interface (IPMI) は、標準化されたメッセージ・ベースのハードウェア管理インターフェースです。IPMI の中核には、ベースボード管理コントローラー (BMC) または管理コントローラー (MC) と呼ばれるハードウェア・チップがあります。 BMC は、システム・ハードウェアのヘルスをモニターするために必要な各種のインターフェースを提供します。ユーザー・チャネル用、要素 (温度、電圧、ファン速度、バス・エラー、その他の要素) のモニター用、手動によるリカバリー (ローカルまたはリモートのシステムのリセットや電源のオン/オフ操作) 用、および異常状態または「範囲外」状態の場合の、将来の検査とアラートのためのオペレーティング・システムによる介入を伴わないログイン用に、さまざまなインターフェースが存在します。 注: BM

  • オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか? その舞台裏と今後の展望 | フルスイング by DeNA

    今後のモノづくりには「インフラ・セキュリティ・品質管理がより一層ビジネスに踏み込んだ動きを取ることが重要になってくる」と考えるDeNA執行役員システム部長のnekokakこと、小林 篤(こばやし あつし)。 そんなnekokakがDeNAのシステム部各部長と「各領域からビジネスに踏みこむモノづくり」について語り合う『モノづくり対談』第2回目をお送りします。 テーマは「オンプレミスに強みを持つDeNAはなぜクラウド化全面移行を決めたのか」。 オンプレの品質コスト世界一を自負するDeNAに、全面クラウド化というドラスティックな意思決定をもたらしたIT基盤部部長・金子 俊一(かねこ しゅんいち)とプロジェクトの全貌を語り合いました。 「クラウド全面移行を決めた理由」「コストの大幅増への対処法」「経営層の意思決定に担当者工数などの課題」など、気になるクラウド化の裏側を解き明かします! ※この記

    オンプレミスに強みをもつDeNAはなぜクラウド化を決めたのか? その舞台裏と今後の展望 | フルスイング by DeNA
  • 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,

    Google、継続的デリバリに対応したデプロイ自動化ツール「Spinnaker 1.0」正式発表。GCE/GKEだけでなく、AWS、Azure、OpenStackなどマルチクラウド対応 - Publickey
    karupanerura
    karupanerura 2017/06/09
    きになる
  • ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ

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

    ウェブアプリケーション開発に新言語を採用したときにインフラで考えたこと - ゆううきブログ
    karupanerura
    karupanerura 2016/03/03
    神エントリだ
  • Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning

    はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。

    karupanerura
    karupanerura 2015/08/14
    Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning
  • 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

    AWSのリソース構成をServerspecのようにテストする "awspec" をつくった - Copy/Cut/Paste/Hatena
    karupanerura
    karupanerura 2015/08/06
    便利っぽい
  • Consul は 全自動オーケストレーションの 夢を見るか?

    - version 1.02 (July Tech Fest の資料アップデート版です) Re: ご注文は自動化ですか?[2] オーケストレーションで仕事を楽しくする話 Serf とか Consul とか聞くけど、イマイチわからん!という疑問はありませんか。 どのような働きをするのかや、使いどころを、皆さんと共有したいなと思っています。 1. オーケストレーションとは ← update! 2. 基編 ・ Serf, Consul, envconsul 3. 実践編 ・ API 連携 4. まとめ #hbstudy 60 http://connpass.com/event/7322/ July 20, 2014, @ Shinjyuku, Tokyo, Japan

    Consul は 全自動オーケストレーションの 夢を見るか?
  • 20150419_pbtech_openstack_nyah #pbtech

    発表日:2016年2月4日 イベント名:ITフォーラム2016 協働プロジェクト『空気を読む家』 イベントURL:http://www.ipsj.or.jp/event/sj/sj2016/IT-F_AITC.html タイトル:AITCと協働プロジェクトの活動概要 概要:先端IT活用推進コンソーシアムの活動と、協働プロジェクトを介して先端技術の利活用イメージをどのように発信しようとしているのかについて、全体概要とコンセプトを紹介します。 発表者:松山 憲和

    20150419_pbtech_openstack_nyah #pbtech
  • Raft

    ↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤:たった一つのプロセスが故障しただけでも有限時間で合意できない 正:たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら

    Raft
  • Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ

    「全体のリソース効率を上げましょう」というためのものである。 Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー これは完璧に正しくて、ただ「リソース効率」という概念はあまり具体的な想像が追い付かない人がいそうだなと思ったので、ちょっとだけ補足しようと思った。 Reverse Proxyを入れることでリソース効率の向上を狙うんだけど、それは以下のような複数の場面におけるそれぞれのリソース効率向上を複合的に狙うものだ。 通常時のトラフィック配信におけるCPU・メモリ使用率を最適化する バースト時(過負荷時)のトラフィックをより細かく制御可能とする 障害時におけるダウンタイムおよび総合的な計算・配信能力の低下を極小化する 多数のサーバによる構成全体を増強・入れ替え・移動あるいは削減する際の自由度の向上を狙う 簡単にコンピュータの性能だけで言うと最初の項目だけをリソース効

    Reverse Proxyがなぜ必要か、勝手に補遺 - たごもりすメモ
  • Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー

    フロントエンジニアに知ってもらいたいリバースプロキシの重要性 | RickyNews この記事が目に入って読んでみた。なるほど、昨今は Reverse Proxy は便利な L7 ルーター的なものとして認識されているのだな、と思った。URL の Rewrite や、VirtualHost 云々。確かに Reverse Proxy の便利な側面ではある一方、それらは Nginx などの Reverse Proxy でなければ実装が不可能かと言えばそんなことはないものでもある。 自分は Reverse Proxy はもうすこしサーバー/インフラ的な側面でその役割を捉えている。今更何をというものでもあるが、昼休みがてら時間があるので簡単に書いてみよう。 Reverse Proxy はWebシステム全体のリソース最適化のためのパーツ Reverse Proxy のインフラ的な視点での役割は「Web

    Reverse Proxy がなぜ必要か - naoyaのはてなダイアリー
  • 1