PostgreSQL Architecture And Performance MonitoringGeeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 ■Geeks Who Drink https://nulab.connpass.com/event/68737/ ■PostgreSQL Conference Japan 2017 https://www.postgresql.jp/events/jpug-pgcon2017
データ分析基盤におけるオブザーバビリティの取り組み
GMOペパボ株式会社では主にGoogle Cloud Platformのサービスを利用してデータ分析基盤を構築し運用しています。その中心となるのがデータウェアハウスのBigQueryとワークフローエンジンのCloud Composerです。また、社内向けのデータ可視化(ダッシュボード)システムではCloud Runを利用しています。 データ分析基盤から得られる情報を重要な意思決定に用いるためには、ユーザーに提供しているインフラと同様に、可用性を明らかにし、継続的に可用性を高める Realiability エンジニアリングが必要となります。本講演ではGCPで構築されているデータ分析基盤を題材として、データ分析基盤に求められる可用性や、小規模なチームにおけるオブザーバビリティへの取り組みについてご紹介します。
Amazon SQS を使ったアプリケーションを本番で運用する際に考慮すべき基本的な 5 つのこと
Amazon SQS は可用性やスケーラビリティの高いメッセジキューサービスであり、AWS の代表的なサービスの 1 つと言えるでしょう。ところが、本番の運用に耐えられるアプリケーションにしようと思うと考えることが意外に多いものです。本エントリーでは簡単なサンプルアプリケーションをベースに、本番で運用するために考慮すべき点・注意点について見ていきます。題材として扱うのが SQS なだけで、SQS 以外を使ったアプリケーションにも応用できる内容もあるでしょう。 なお、SQS には Standard queue と FIFO queue がありますが、Standard queue を使う前提とします。 アジェンダは次のとおりです。 サンプルアプリケーション 1. ログ 2. At-least-once delivery と visibility timeout 3. デプロイ 4. 異常系 5
LINEのメッセージングサーバが新年のトラフィックに対応する過程
はじめに LINEの通信トラフィックは、メッセンジャーアプリ特有のパターンを持っています。新年の0時を迎えた瞬間に、ユーザ同士がLINEで新年のあいさつを交わしていることが想定され、それにより平常時に比べてメッセージの送信件数が大幅に増加します。その際、サービスを提供する国ごとに、時差や文化の違いによってさまざまなトラフィックの増加パターンを見せます。LINEでは、このような一時的なトラフィック増加を問題なく処理するため、毎年さまざまな対策を行っています。これを「新年対応」と呼んでいます。本記事では、2020年の新年対応における私たちの取り組みと、成果についてご紹介します。 LINEのメッセージングサーバが新年のトラフィックに備えるプロセス 各国で新年の0時になると、多くのユーザがLINEで新年のあいさつメッセージを送っていると想定されます。そのため、平常時より一時的にトラフィックが大幅に
[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules
[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules
![[CNDK2019]Production Ready Kubernetesに必要な15のこと / Production Ready Kubernetes 15 Rules](https://cdn-ak-scissors.b.st-hatena.com/image/square/a86024b552674b0bd8fcbfe3dd22d43a58b0e2d4/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F427afd1dcd624e4080e6358129c1b754%2Fslide_0.jpg%3F14872086)
サーバ「管理」ツールとしてのMackerelの起源 - ゆううきブログ
この記事は、SaaSのサーバ監視サービスMackerelを起源を遡り、そこから現在の姿に至った経緯をはてな社内のエンジニアに共有するためのものです。 なお、ここに書かれていることは、Mackerel開発チームの公式見解ではありません。 概要 Mackerelは、もともとは2007年ごろに開発されたはてなの社内のサーバ管理ツールであり、動的なインフラストラクチャに対応するために、現在でいうところのInfrastructure As Codeを目指したものです。 そこから2013年にSaaSのサービスとして開発され、コードベースとアーキテクチャは全く新しくなり、監視機能を備え、サーバ「監視」サービスと呼ばれるようになりました。 しかし、はてな社内では、プログラマブルなAPIを備えたサーバ「管理」サービスとして、Mackerelを中心にしたインフラストラクチャを構築しています。 Mackerel
高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ
名古屋大学で開催されたIPSJ-ONE2017 で登壇しました。 IPSJ-ONEというのは、情報処理学会の各研究会から選ばれた日本の若手トップ研究者17人が集まり、自身の研究を高校生でもわかるように発表するイベントです。 1000人ぐらい入る講堂で、しかもニコニコ生放送で配信されるというとても大掛かりなイベントです。 ちなみに、昨年は、同じ研究会からの推薦で、 id:matsumoto_r (matsumotory) さんが登壇されています。 IPSJ-ONE 2016で登壇してきた - 確実に時代は変わってきている #ipsjone - 人間とウェブの未来 発表 「高度に発達したシステムの異常は神の怒りと見分けがつかない」という、一見何の話かわからないやばそうな話なんですが、大真面目に話してきました。 スライドを以下に公開しています。ただ、スライドだと何の話をしているかおそらくわからな
Sensu と Graphite による大規模インフラの監視
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション本部の渡邉です。 サイトオペレーション本部はデータセンタ・ネットワーク・サーバー・OS・ストレージといった全社的なインフラの管理運用や調査検証などを担当しています。 今回は、2013年に全社のプライベートクラウドとして導入した OpenStack の監視基盤として、OSS の Sensu と Graphite を採用した事例についてご紹介したいと思います。 採用に至るまで サイトオペレーション本部では、もともと 2011 年から内製のプライベートクラウドを開発運用していました。 プライベートクラウドでは VM のホストとなるハイパーバイザを大量に運用する必要がありますが、その監視基盤として社内で一般的に利用され
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
