タグ

負荷に関するhigedのブックマーク (11)

  • なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか

    こんにちは。Infra Study Meetup 運営の重です。先日 4月24日(金)夜に開催したオンライン勉強会「Infra Study Meetup #1『Infrastructure as Code』」において配信トラブルが発生し、ライブ配信開始から45分にわたり1000名を超える参加者に多大なるご不便をお掛けしてしまいました。記事では、今回のトラブルの原因およびリカバリー方法、再発防止策についてまとめ公開いたします。 概要 勉強会は2020年4月24日(金) 19:25より、YouTube Live を用いてオンラインで開催しました。 発表者には Zoom ミーティングを用いて画面共有および発表していただき、その様子を配信ソフトを介した上で YouTube Live で配信するという構成です。 配信開始直後の19:25〜19:35の間、YouTube Liveでのライブ視聴が

  • サーバレス時代の負荷テスト戦略 〜CircleCIで実現する継続的負荷テストとチューニングTips〜 - Qiita

    負荷テストとサーバレス 負荷テストに対する考え方は時代とともに変化してきました。従来はサーバスペックやシステムの限界性能を測るという考え方でしたが、クラウドネイティブなシステムではそれに加えて、システムの弾力性(スケールアウトのしやすさ)も考慮する必要があります。 記事では、負荷テストによるシステムの弾力性の評価と、改善する方法についてツールの具体的な使用方法やアプリケーションのチューニング Tips を交えて説明します。システムの弾力性を評価するために、プロダクション環境でのユーザからのリクエストを想定したロードテストを検討します。 ロードテストでは以下の項目を検証します。 ドリップテスト ドリップテストは通常、数日間にわたって行われます。通常のバックグラウンド負荷レベルをシミュレートします。遅延またはエラー率の増加が見られる処理を特定します。 スラムテスト スラムテストは、トラフィッ

    サーバレス時代の負荷テスト戦略 〜CircleCIで実現する継続的負荷テストとチューニングTips〜 - Qiita
  • PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと

    PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと PayPay 100億円キャンペーンのシステム構築 #1/2 2019年6月12〜14日、幕張メッセにて「AWS Summit Tokyo 2019」が開催されました。アマゾンウェブサービス (AWS) に関する情報交換や、コラボレーションを目的として行われるこのカンファレンスでは、140社以上の利用企業による先進事例セッションをはじめ、数々のイベントを実施しました。プレゼンテーション「PayPay 100億円キャンペーンのシステム構築 」に登壇したのは、PayPay株式会社プロダクト部の山啓介氏とShilei Long氏。スマホ決済アプリとして新規参入した同社が展開し、日中の話題をさらった「100億円キャンペーン」の技術的背景について語ります。前半パートとなる今回は、山

    PayPayエンジニアが明かす「100億円キャンペーン」のシステムの舞台裏 数々の問題を解決するためにやったこと
  • 巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明

    はじめに この記事は設計・アーキテクチャ Advent Calendar 2018の1日目の記事です。 大きなサービスを支えるのは一筋縄では行かず、考えることは多くあります。しかし、ありがたいことに巨大な企業の中にも自社のサーバー構成やそれを支えるツールを公開している企業があります。 この記事では、彼らの叡智に触れるため、有名企業の事例を取り上げ要約をします。 各事例には元記事へのリンクを書いているので、興味があればリンク先も覗いてみてください。 ※新しいものばかりではないので、古くなっていたり既に別の方法に移行している可能性があることに注意してください。 LINE: 25k/secのスパイクをさばくアーキテクチャ 元記事: 25K request/secをさばいた「LINEのお年玉」のアーキテクチャの裏側 最初に紹介するのは、LINEが2018年に実施した、「LINEのお年玉」というイベ

    巨大企業のサーバー構成や内部ツールを覗く - 発明のための再発明
  • ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 - Publickey

    ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 ファーストサーバが提供しているホスティングサービス「Zenlogic」は、6月下旬から断続的に生じていたストレージ障害に対応するためのメンテナンスが終了の見通しも立たないほど難航し、結局、メンテナンス開始から3日後の夜にようやくサービスが再開されるという事象を起こしました。 参考:ファーストサーバのレンタルサーバ「Zenlogic」、金曜夜からの全面サービス停止が解けず、いまだ停止中。ストレージ障害のためのメンテナンスで(追記あり) - Publickey サービス再開から約1週間が経過した7月17日、同社はストレージ障害に関する原因およびメンテナンスによるサービス停止が長期化してしまった原因、再発防止策についての報告書を明らかにしました。 報告によると、ストレージ障害の直

    ファーストサーバのZenlogic、ストレージ障害の原因は想定以上の負荷、対策したはずの設定にミスがあったため長期化 - Publickey
  • Zenlogicサポートサイト[IDCフロンティア]

    TOP サービス IDCFクラウド コンピュート コンテナ RDB CacheDB クラウドストレージ DNS GSLB(広域負荷分散) インフィニットLB CDN イメージオプティマイザー 連携サービス プライベートクラウド NSXオプション ベアメタルサーバー パートナーサービス Fastly CDN Fastly 次世代 WAF SiteGuard Server Edition Google Cloud 構成例 事例 料金シミュレーション ウェビナー開催情報 今後の機能強化予定 English

    Zenlogicサポートサイト[IDCフロンティア]
  • FGO を支える負荷試験ツール

    これはアカツキとディライトワークスが共同で主催している “FGOなど大規模ゲームの課題から学ぶゲームサーバ・インフラ勉強会” での LT 発表資料です。こちらの資料に軽く補足を入れながら話をしていきます。 時雨堂では FGO の検証に利用するための負荷試験ツールを提供しています。 先日、大きめのメンテナンスが無事終わり、ほっとしています。 さて、メンテが無事終わって、FGO の中の人から以下のようなありがたいメッセージをもらいました。 負荷試験ツールなくしては今回の改修はなしえなかったと思いますので当にありがとうございました…。その負荷試験ツールがどんな仕組みで、どんなことを実現しているのかを書いていきます。時雨堂が負荷試験ツールで実現したことのみを書きます。 主に技術的な話というよりはこんなことやったよがほとんどです。 番データを利用した負荷試験利用されている負荷試験ツールは、時雨堂

  • モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9

    スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー(MySQL)を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。

    モンストのサーバー負荷との戦い 〜あけおめ2018編〜 / bcu_30_server_9
  • コマンドによる「負荷」の原因切り分け

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    コマンドによる「負荷」の原因切り分け
  • 宁波逼拘旅行社

    宁波逼拘旅行社
  • Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO

    負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観

    Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO
  • 1