Storage | Prometheus
Getting startedInstallationConfigurationConfigurationRecording rulesAlerting rulesTemplate examplesTemplate referenceUnit Testing for RulesHTTPS and authenticationQueryingBasicsOperatorsFunctionsExamplesHTTP APIRemote Read APIStorageFederationHTTP SDManagement APICommand LineprometheuspromtoolMigrationAPI StabilityFeature flags VisualizationExpression browserGrafanaConsole templates InstrumentingC
100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫
100億円キャンペーンで学んだ“教訓” PayPayのスケーラブルな巨大決済システムを支える工夫 PayPay 100億円キャンペーンのシステム構築 #2/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス （AWS） に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト本部の山本啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日本中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。後半パートとなる今回は、Shilei Lo
秒間100万リクエストをさばく - Googleの共通認可基盤 Zanzibar - 発明のための再発明
はじめに Googleの提供するサービス郡が共通して利用している認可システムにはZanzibarという名前がついています。ZanzibarはGoogleDrive・Google Map・Youtubeなどの巨大なサービスにも使用されています。 そのため、利用量も凄まじく 数10億のユーザー 数兆のACL(access control list) 秒間100万リクエスト もの量をさばいています。 にも関わらず、Zanzibarはこれを10ミリ秒以内に返します(95パーセンタイル)。 この記事では、そんなZanzibarの内部構造に関する論文「Zanzibar: Google’s Consistent, Global Authorization System」の中から、主に大量のリクエストをさばくための工夫を紹介します。 ちなみに、以前Googleの社内システム用の認可システム「Beyond
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 － Publickey
ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 ファーストサーバが提供しているホスティングサービス「Zenlogic」は、6月下旬から断続的に生じていたストレージ障害に対応するためのメンテナンスが終了の見通しも立たないほど難航し、結局、メンテナンス開始から3日後の夜にようやくサービスが再開されるという事象を起こしました。 参考：ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） － Publickey サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。 報告によると、ストレージ障害の直
ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり）
ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで（追記あり） ファーストサーバが提供しているホスティングサービス「Zenlogic」で、本日午前8時に終了予定だったメンテナンスが終わらず、月曜日の午前9時を過ぎた記事執筆時点でサービスが停止したまま、終了時間が未定になっています。 （2018/7/9 15:47追記） 同社は障害の調査と平行して、基盤提供元のヤフー株式会社とともに別基盤の構築準備作業を実施していると報告しています。ただし「本日中に目途をお伝えするのは厳しい状況でございます。」とのことで、明日10日火曜日までサービス停止が継続する可能性を示唆しています。 （2018/7/9 22:50追記）同社は一時的にサービスの再開を発表、下記の記事を公開しました。 ファーストサーバの「Zenlo
Mac使いのNAS初心者に何の説明もなくNASキットを送りつけた結果（設定編）
Mac使いのNAS初心者に何の説明もなくNASキットを送りつけた結果（設定編）：「NASって簡単」は本当か（1/2 ページ） iPhoneでスマートフォンデビューしてはや7年。Apple製品の“分かりやすさ”に惚れ、iPad、Macと少しずつ手に入れてきました。しかしデバイスが増えるにつれ、写真、動画、音楽など扱うデータは増えるばかり。MacにiPhoneのデータをバックアップしようものならあっという間に数GBが消費され、筆者のMacBook Proくん（SSD、128GB）はヒーヒー悲鳴をあげます。かわいそう。 そういえば回りでも、「iPhoneの容量が足りなくてOSのアップデートができない」「何年も前の写真から保存されているけど、iCloudがいっぱいでバックアップできていない」など、ストレージの問題をよく耳にします。不要なデータをこまめに消すのは限界があるけれど、難しいことはしたくな
「Hadoopの時代は終わった」の意味を正しく理解する - 科学と非科学の迷宮
Hadoopの時代は終わった、という言説をたまに見かけるようになりました。 もちろん終わってなどいません。しかし、Hadoopとその取り巻く環境が変化したのは事実です。 本記事では、この変化が何なのかを明らかにし、その上で、なぜHadoopの時代は終わったという主張が実態を正しく表していないのかを説明していきます。 DISCLAIMER 私はHadoopを中心としたデータ基盤を取り扱うベンダー、Clouderaの社員です。 中立的に書くよう努めますが、所属組織によって発生するバイアスの完全な排除を保証することはできません。 以上をご了承の上、読み進めてください。 要約 データ基盤は、Hadoopの登場により非常に安価となり、今まででは不可能だった大量のデータを取り扱えるようになりました。 Hadoopは、NoSQLブームの中、処理エンジンであるMapReduceとストレージであるHDFSが
インテル、ついに不揮発性のメインメモリ「Intel persistent memory」発表、実稼働デモ公開。2018年に新型Xeon「Cascade Lake」とともに登場予定
Intel persistent memoryはデータの保持に電力を必要としない、不揮発性メモリの一種だ。データをメモリからストレージに保存する必要がなくなるなど、コンピュータのアーキテクチャを一変させる可能性を持つ。 現代のコンピュータは基本的にメインメモリとしてDRAMを利用しています。DRAMはアクセスが高速な一方、容量あたりの単価は高く、それゆえ大量にコンピュータに搭載することが難しく、またデータを保持し続けるのに電力を必要とします。 このDRAMの能力と性質を補完するため、一般に現代のコンピュータには二次記憶装置として大容量で安価かつ電力がなくてもデータを保持し続けられるハードディスクドライブなどのストレージを備えています。 こうした現代のコンピュータの構造を一変させようとインテルが5月16日に発表したのが、大容量かつ低価格、しかもデータの保持に電力を必要としない、同社とマイクロ
RAIDコントローラのキャッシュ構成 - とあるSIerの憂鬱
コントローラがもっているキャッシュは『コントローラ・キャッシュ』と呼ぶ。 コントローラ・キャッシュをライト・キャッシュとして使用する場合、電源断でキャッシュ内容が消失しないよう、バッテリを内蔵する。 バッテリが無い場合、バッテリの充電が十分でない場合はライト・キャッシュを使用しないライト・スルーに自動で切り替わる。 バッテリ動作の期間内にコントローラ・キャッシュの内容を保持するだけでなく、不揮発のフラッシュ・メモリに書き込むものもある。 リード・キャッシュは効果が少ないため、HPのコントローラではリード・キャッシュ25%、ライト・キャッシュ75%の比率がデフォルト。 コントローラ・キャッシュはRAIDのパリティ計算などコントローラの作業用メモリとしても使われる。 HDD自体が持っているキャッシュ(バッファ)は『ディスク・キャッシュ』と呼ぶ。 サーバ向けのHDDではディスク・キャッシュは通常
快適な連打機能を提供するためにサーバサイドが出来ること - その手の平は尻もつかめるさ
人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！ しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ストレージの基礎
Zenlogicサポートサイト［IDCフロンティア］