JVMアプリケーションを運用する際のメジャーどころチューニングポイントメモ - yoskhdia’s diary
JVMにチューニング項目は多々あれど、プロダクションで運用する際に予めおさえておきたい項目をまとめてみるエントリです。*1 勿論、OSもJVMもデフォルトである程度のパフォーマンスは発揮でき、計測を伴わないチューニングは悪手であることはよく知られています。 しかし、設定しておかないとパフォーマンスにそのまま影響すると分かるものを調べないのは裸で戦場に赴くようなものです。*2 どんな項目をどう変更すれば良いのか知っていることは重要な武器なのです。 なぜ調べるのか 今回、チューニングポイントを調べるにあたって、私のモチベーションはどこにあるのかを考えると、以下の要件を満たしたいということがあげられます。 アプリケーションとして求められる品質水準として動作する → 性能目標 異常時に事象を追うことができる ここでいう品質水準・異常とは、パフォーマンスが明らかに低い、アプリケーションがクラッシュす
「当たり前に動いている」ネットワークを支える技術 - 冗長性を生み出すバックボーンの構成を、さくらインターネットに聞く - はてなニュース
レンタルサーバーやクラウド、ハウジングサービスといった、ネットワークの基盤を支えるサービスは、どんな時でも当たり前に稼働し続けることが求められます。しかし、この「当たり前」を実現するには、地震や台風といった、予測のつかないリスクへの備えが不可欠です。 さくらインターネットは、2018年9月に発生した北海道地震の際にも安定した運用を継続し、利用者に安心感をもたらしました。同社のサービスが安定運用を続けることができるのはなぜか？ 先日紹介したデータセンター運用に続き、今回はネットワークの安定運用に焦点を当て、同社の技術本部ネットワークグループの3名に聞きました。 ※この記事は、さくらインターネット株式会社によるSponsoredContentです。 石狩、東京、大阪を結ぶトライアングルネットワークが冗長性をつくりだす ネットワークの中の人が見る、トラフィックのいま ネットワークを「湯水のように
パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生 ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず
パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生 ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず CDNプロバイダーのCloudflareで障害が発生。世界協定時4月15日の午後3時31分から午後7時52分まで、ダッシュボードおよびAPIが使えない状態だった。原因は、作業を指示された技術者が、パッチ盤からケーブルを引っこ抜いたことだったという。 CDNプロバイダーのCloudflareは、世界協定時4月15日の午後3時31分から午後7時52分（日本時間4月午前0時31分から午前4時52分）まで、ダッシュボードおよびAPIが使えなくなるという障害を発生していました。 同社のブログ「Cloudflare Dashboard and API Outage on April 15, 2020」によると、同社の2つのコアデータセンターのうちの1つで、パッチ盤から
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？
SpotifyがミスによりKubernetesの本番クラスタを二度も削除。しかし顧客へのサービスにほとんど影響しなかったのはなぜか？ 今年、2019年5月20日から3日間にわたりスペイン バルセロナで開催されたKubeCon＋CloudNativeCon Europe 2019の基調講演では、SpotifyがミスによってKubernetesのクラスタを消去してしまった経験を振り返るという非常に興味深いセッション「Keynote: How Spotify Accidentally Deleted All its Kube Clusters with No User Impact - David Xia」（基調講演：SpotifyはいかにしてKubernetesクラスタの全削除というミスにもかかわらず顧客への影響を引き起こさなかったのか？）が行われました。 障害が起こることをあらかじめ計画とし
[技術ブログvol.21] インフラ視点で、負荷テストについて考えてみる - DENET 技術ブログ
負荷テストは、インフラ環境をサイジングするうえでの具体的なデータを与えてくれます。この記事では、インフラ事業者視点で負荷テストについての目的、種類、実施方法について考えてみます。 ※面倒な準備は無しで、簡単に負荷テストを実施したい人向けに、WEBインタフェースから負荷テストがおこなえるシステムを作成中です。 インフラ事業者から見た、負荷テストの目的 サイジングの妥当性を証明できる インフラ事業者から見た場合、負荷テストの最大のメリットはサイジングの妥当性を証明できることです。 当社も提案の際に、サイジングに必要な情報を確認していきます。月間の（想定）アクセス数、ピーク時の（想定）アクセス数、平均ページサイズ、リプレイスであれば各サーバのCPUやメモリ、ディスクなどのリソース情報などです。しかしながら、具体的な情報がでてくることは多くありません。そのため、想定しているアクセス数やシステムの内
![[技術ブログvol.21] インフラ視点で、負荷テストについて考えてみる - DENET 技術ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/33184e9b1ec8b646021561cd25873e5232aa45f2/height=288;version=1;width=512/https%3A%2F%2Fblog.denet.co.jp%2F2014%2F12%2Faz2_test.jpg)
インフラチーム改め Site Reliability Engineering (SRE) チームになりました
インフラチーム改め Site Reliability Engineering (SRE) チームになりました Organization Author: kazeburo インフラチーム改めSite Reliability Engineering チームの @kazeburo です。この記事ではまだ馴染みの薄い Site Reliability Engineer とは何かについて紹介したいと思います。 SREとGoogleのSRE Site Reliability Engineerは日本語にすると「サイト信頼性エンジニア」となりますが、あまりキャッチーではないので普段は略語の「SRE」を使用しています。SREという職種は日本ではあまり聞く事はありませんが、FacebookやAirbnb、Dropboxなどの企業でSREが募集され、それぞれのサービスを支える重要な役割を担っていると思われます。
Mackerel（マカレル）: 新世代のサーバー管理・監視サービス
監視を育てる、Mackerel クラウド時代に最適な監視モデルを使いやすいUIで提供し、システムの運用・監視にチームで取り組む文化を作る「クラウド運用の道標」となるSaaS型サーバー監視サービス。 特長 Mackerelが選ばれる理由 Mackerelは、株式会社はてなが提供する日本製のサーバー監視サービスです。自社のサービス運用基盤をMackerelで運用し、そのノウハウを詰め込むことで、クラウド監視に必要な機能を提供し続けています。 圧倒的に手軽な導入 サーバーに監視エージェントをインストールするだけで、すぐにサーバー監視を始められます。 詳しく見る 育てる監視 様々なコミュニケーションツールとの連携によりチームでの情報共有を促進し、システムの状態に合わせて監視を育てるきっかけを作ります。 詳しく見る 高度な監視 複数メトリックの組み合わせや将来の予測値の監視、機械学習を使って過去の傾
アーキテクチャ刷新プロジェクト「Neco」の紹介 - Cybozu Inside Out | サイボウズエンジニアのブログ
@ymmt2005 こと山本です。 今回は開発本部と運用本部のメンバーが協力して進めている cybozu.com やサイボウズ Live のアーキテクチャ刷新プロジェクト「Neco」について紹介します。 Neco を 3 行で説明すると、 サイボウズのクラウドインフラのいけてないところを洗い出して、 5 年程度を目安に改善するつもりだけど、 やりたいことが多すぎるので、We are hiring! で済んでしまうのですが、それだけでは面白みに欠けますので、いけてない内実を暴露しながら解説いたします。 サイボウズはクラウド 5 年生 正確に言うとサイボウズ Liveなど一部のサービスはもっと以前から取り組んでいたのですが、本格的にクラウドサービスといえるインフラを構築してサービス提供を開始したのは今から 4 年前の 2011 年 11 月となります。そこでオープンしたのが cybozu.co
How we upgrade a live data center - Server Fault Blog
A few weeks ago we upgraded a lot of the core infrastructure in our New York (okay, it’s really in New Jersey now – but don’t tell anyone) data center. We love being open with everything we do (including infrastructure), and really consider it one of the best job perks we have. So here’s how and why we upgrade a data center. First, take a moment to look at what Stack Overflow started as. It’s 5 ye
Cross-Region 系パターンを整理してみる（新CDP提案あり） | iret.media
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 CDP Advent Calendar 2013 の6日目です。 今日は Cross-Region なクラウドデザインパターンを考えてみます。 ■前提で押さえておきたいこと Webの3層構造を主体に考えます。まずはWeb/APサーバーやデータベースの特性を押さえておきましょう。 Web/APサーバ スケールアウト/インの水平スケールが容易 ロードバランサーやDNSによる負荷分散方法がある 負荷分散方法があるので基本的には全てのノードはアクティブ-アクティブにできる マシンのテンプレートは本来1つあればよいが、サービスの実装上、リージョンごとに同じテンプレートを置いておく必要があることもある（AWSだと今のところそう）。これはサービスの仕様の問題。 データベース データベースには以下のような構成が考えられます
GCP リージョン跨ぎロードバランサーの破壊力 - 続 カッコの付け方
知っている人は知っている、GCP(GCE)のロードバランサーはリージョン跨ぎができます。昨年10月頃？より、Developers Consoleから確認できるロードバランサーは2つになりました。 ネットワーク負荷分散 HTTP負荷分散 このうち、リージョン跨ぎロードバランサーはHTTP負荷分散の事になります。ただしこちらのロードバランサーはまだBetaとなっています。さらに正確には HTTP負荷分散は 本エントリの Cross-Region load balancing と Content-based load balancing の2つがあります。 リージョン跨ぎロードバランサーの目的 複数リージョンに割り振るが、アジア圏のユーザーのリクエストはアジアリージョンのサーバに飛ばし、早いレスポンスを保つ。 リージョン間でfail-overする。例えばアジアリージョンのサーバが全滅したら、アジ
インフラエンジニア不在で120万人のユーザーを支える方法 - Eureka, Inc.
はじめまして、WEBエンジニアの石橋です。 エウレカではpairs全体の開発責任者としてサーバサイドの開発・管理、インフラの構築・管理を行っています。また、数字やリソースの計画・管理など一部プロデューサー業務も担当しています。 前々職では受託のWEBエンジニアを4年、前職では自社サービスの基幹システムやECシステムのインフラ構築・開発などIT部門の統括、物流・CS部門の統括、自社メディアのプロデューサーとしてマルチタスクな4年間を過ごしていました。 趣味は漫画を読むことです、が最近インフラ周りに時間を取られてなかなか読めていません。。漫画が読めない時間が長く続くと、自分の中の何かのエネルギーがどんどん減っていきいずれは枯渇するような気がしてなりません。1分でも多く漫画を読む為にも、まずはしっかりインフラを整備せねばと今日も仕事に励んでいます。 さて今回は初めての投稿ですので、まずは先日会員
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
はてなで大規模サービスのインフラを学んだ - ゆううきブログ
中〜大規模サービスのインフラの様子を知りたいアプリケーションエンジニア向けに、もともとアプリケーションコードを書いていた視点から、個人的な体験をベースにはてなで大規模サービスのインフラを学んだ過程や学んだ内容の一部を紹介します。 Webアプリケーションのブラックボックス Webアプリケーションフレームワークの向こう側 なぜ複数のサーバが必要なのか 突然のWebサービス3層構成 リバースプロキシ アプリケーション データベース その他のコンポーネント キャッシュは麻薬 飛び道具としてのKVS/NoSQL 非同期処理 バッチ処理 Mackerelの場合 参考 まとめ Webアプリケーションのブラックボックス 今年もはてなインターンの時期が近づいてきた。 毎年ではないけど、はてなインターンでは「インフラ講義」というのをやっている。 今年はインフラ講義の講師としてアサインされたのでちょうど何を話そ
「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説
クラウドを活用した本番システムのデプロイ手法の1つに「Blue-Green Deployment」がある。Blue-Green Deploymentの目的とそのメリットを、マーチン・ファウラー氏の解説から紹介する。 1つ前の記事で紹介した、チャド・ファウラー氏によるImmutable Infrastructureの記事「Immutable Infrastructure（イミュータブルインフラストラクチャ）と捨ててしまえるコンポーネント」では、デプロイをより安心して行うために、サーバの内容を変更する際には既存のサーバに手を加えるのではなく、新規に作り直して切り替える、という方法を提案しています。これがサーバの不変性、すなわちImmutable Infrastructureにつながるわけです。 これから紹介するマーチン・ファウラー氏の記事「BlueGreenDeployment」は、Immut
chef-soloのセットアップとchefについての私感 - Qiita
買いました。 入門Chef Solo - Infrastructure as Code 読みました。 chef-soloの触りとchef-server環境の作成ぐらいは出来たのであの丘の向こうを目指して使い心地とかまとめておきます。 chefとは 引用: 入門Chef Solo #23 どこまでをChefでやるべきか chefは「ノードの状態を管理し、そのノードをあるべき状態に収束させるフレームワーク」だからです。 と、あるようにchefはサーバーをあるべき状態に収束させるフレームワークです。 サーバーの初期環境構築や設定ファイルの変更等をしてくれます。sshでログインしてパッケージインストールや設定ファイルの変更をしなくても目的のサーバーの状態にしてくれます。 chefの種類 単一で機能するchef solo 複数を管理するchef server&chef client がある。 どちら
「GREEを支える大規模インフラテクノロジー」-GREE Platform Summer Conference 2012
取締役 執行役員CTO 開発本部長 藤本 真樹氏 2005年6月にGREEに入ってから7年が経ちました。 GREEでは開発全般を見ていて、最近はインフラよりもクライアントの方を見ますが、元々はサーバーサイドよりの人間なので、今回こういう話ができて嬉しいです。 今回のお題でサーバーサイドに関して話してみては？ と言われて、すごく困ってしまった。 何故かというと、大規模サービスを普通にやるテクノロジーのコモディティ化が進んだからです。 １０倍のユーザーが来た時にどうすればいいのかというのは、インターネット上にいっぱい情報が既にあり、それを支えるオープンソースのプロダクトや、クラウドサービスなど解決策がいくつもある。 Agenda 1.Infrastructure for over 100,000,000users 2.Infrastructure for global ser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Statuspage | Atlassian
【インタビュー】ナンバーワンポータルを支える心意気 ～Yahoo!JAPANを支えるインフラ技術者に聞く 
http://www.ohmasa-gas.org/