Webアプリ負荷試験ガイド 目次 Webアプリ負荷試験ガイド 目次 前置き 時間がない人向け要約 about me 何故負荷試験を行うのか 負荷試験ツール 負荷掛けるツール 負荷計測 負荷の可視化 負荷試験の流れ 負荷試験スケジュールについて 注目すべきポイント シナリオ作成 アカウント情報は自動生成出来るようにする DB分割を行ってる場合はDB分割を意識したシナリオを用意する。 負荷試験元 http or https サーバ1台 サーバ単体での負荷 アプリの正常性の確認 サーバ複数台 KVS Memcached Redis RDB 問題になりやすいDB キャッシュの話 大前提 注意すべき点 CDNやProxyレベル local cache or remote cache local cache or memory cache(in app cache) references 更新情報 前
皆さんこんにちは、エンジニアの西尾です。 新しい機能・サービスを開発する際、私は特にデータベース設計に気をつかいます。 データベースはシステムの土台です。 土台が不安定だと、その上に積み上げていくアプリケーションコードがいびつなものになり、つらい思いをします。 また、一度動き出してしまったシステムのデータベース設計を変えるのは、容易なことではありません。 データベース設計には”これだ！”という正解はないと思っています。 サービスの特徴、システムの性質、toB向け/toC向け、Readが多い・少ない、Writeが多い・少ない。 その他もろもろの背景により、データベース設計の仕方も変わってきます。 このテーブルは正規化していないから駄目だ、この設計はいわゆるポリモーフィック関連だから使ってはいけない、などということはありません。 アンチパターンと呼ばれるものも時と場合によっては正解になります。
良いコードを書くための8つの習慣
New Relic Now Start training on Intelligent Observability February 25th.
はじめに inspired mogaさんのブラウザで動くサービスを作るときの技術選定が素晴らしい記事だったので、自分も書いてみる事にしました。 幸いにも技術選定からのお仕事をする機会が多くて、自分の中でパターンが大体決まってきているので言語化してみます。前提が同じサービスは無いので絶対的な正解は無いですが、なんかしらの参考になれば幸いです。 ※2022/02時点 私/よくあるお仕事について Web系のサービスなんかいい感じにするマンとして、フリーランスとして働いています。 準委任という形でスタートアップ企業をお手伝いする事が多いです。 MVPを作りたい、もしくはMVPは行けたのでちゃんと作り直したい、という要望があって参画して、まるっと作ってそのまま運用をします。作って終わりではなくて、運用や拡張性を考えてやってます（サービスに必要なのはもちろん、運用する自分が楽だから）。 前提 エンジニ
PayPayの1秒あたり1000決済への道のり
パフォーマンス・チューニングに関するブログの第１回目です PayPayは、日本でもっともよく知られているQR決済サービスとなりました。2018年10月5日のローンチ後、2018年12月より実施した100億円あげちゃうキャンペーンは、その後のプロダクトの急成長に合わせたシステムのスケール拡張という長い道のりのスタート地点でもありました。 ここ数ヶ月の新規ユーザーの増え方[1]を見るにつけても、PayPayが驚異的な成長を続けていることは間違いありません。スタートアップ企業はまるで竹のように成長するとはこのことではないでしょうか。（竹は24時間で最大約90cmも伸びるそうです） PayPayの成長速度は？ ユーザー数の伸び 2018年10月に初めてユーザーが増え、キャンペーンや日々メディアで報道されることによるユーザー数の増加もあり、1年後には1500万人を突破しました。2020年5月現在、サ
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
60億円の損害を出した 「DMMブックス」 70％OFFキャンペーンでプラットフォームに何が起きていたか
ログ基盤をCloudWatchLogからNewRelic Logs + S3に変えたら 利便性も上がってコストも下がった話
はじめに 何を書こうか迷ってたんですが、ちょうど副業始めて1年ほどたったので、どういうきっかけで始めたか、何をしてるのか、やってみたメリットなどを書いていこうと思います。 なぜ副業×AWSなのかというと、自分が副業をやっていく中で普段AWSに触れていることが強みになっていたので、単に副業だけじゃなくAWSも混ぜてみました。 これから副業を始めようと思っている人、特に本業で役割が変わってあまりコード書けなくなった人に参考になれば。 自己紹介 本業ではSREという部署でCloud Architecture Grpというチームを持っており、自社サービスであるCOMPANYのクラウドネイティブ化を推進しています。 主にクラウドプラットフォームとしてはAWSを利用しているため、日常的にAWSのサービスに触れる機会が多いです。 そんな本業の傍ら、3社で副業やってます。(20名規模ぐらいのベンチャー)
Amazon RDS Proxy が BASE にもたらした期待以上の導入メリット - BASEプロダクトチームブログ
はじめに 基盤チームでバックエンドエンジニアをやっている松田（ @tadamatu ）です。 以前にCTO川口が当ブログ内で公開した以下の記事があります。 devblog.thebase.in 新規接続の限界 BASE のアクセス量の伸びは凄まじくこの構成でも接続エラーが発生するようになってしまいました。 ピーク時に秒間 2 万もの新規接続が primary インスタンスへ行われているといった状態です。 この記事が公開されたのが約２年前で、当時100万程度 だったショップ数は170万を超え、我々はまだまだ伸ばしたいと考えています。 これは、ショップ数の伸びとともに、指数関数的に増えていくユーザのアクセスを捌く必要があることを意味します。 ブログ公開当時、我々はさまざまな検討の末、以下のような対策を取りました。 残された手段は primary のインスタンスに対しての接続数を如何にして減らす
決済システムでは、高い耐障害性やスケーラビリティ、柔軟性、またデータの整合性等が特に高度に求められる領域です。本特集では、決済基盤の開発・運営に携わる6社のエンジニアの方々にご協力頂き、決済システムにおける技術選定のポイントや今後の展望を、アーキテクチャ図と共に解説頂きました。 ※ご紹介は企業名のアルファベット順となっております 合同会社DMM.com合同会社DMM.comは、会員数4,507万人（※）を誇る総合サービスサイト「DMM.com」を運営しています。 1998年の創業以来、多岐にわたる事業を展開し、現在は60以上のサービスを運営。動画配信や電子書籍、アニメなどの多様なエンタメサービスに加え、3DプリントやEV充電などのハードウェア分野、AIといった最先端のテクノロジーを取り入れた事業など、様々な事業を手掛けています。 2022年にはサブスクリプション会員システムの「DMMプレミ
Javaがサーバレスに至るまでの道のり
はじめに 先日、JakartaOne Live Japan 2022というイベントで登壇させていただく機会を頂きました。 QuarkusやHelidonのような新しめのEEフレームワークがこれまでのPayaraやWebLogicとどう違うのか？ CloudRunのようなサーバレス環境でMicroProfileのどの機能が効果的に働くのか？ という点を最近のWeb開発周りのトレンドと絡めながら話ました。上記のようにアーカイブ動画も公開されていますが、せっかくなのでQuarkusがサーバレス環境で実行に最適化されるまでの周辺事情等をまとめたいと思います。Javaだけに留まらず最近の環境事情の整理にも役立つかと思います。 TL;DR Quarkus/Helidonは軽量で高速な新しいEEフレームワーク コンテナや、サーバレス、クラウドネイティブなど最新のトレンドに基づいた設計 GCPのCloud
入社したらAWSコンソールにCloudWatchアラームが1000個以上あったので整理してる話 - Uzabase for Engineers
こんにちはNewsPicks SREチームの飯野です。 今年の1月入社の新入社員です。そろそろお仕事に慣れてきました。今回は研修と研修の合間に地道に行っていたCloudWatchアラームの整理について話していきたいと思います。ちょっと長くなりますがお付き合いください。 よくわからないしアラームを整理しよう まずはスプレッドシートで一覧してみよう 整理の方針を決めよう さまざまな問題をかかえたアラームたち Case#1 AlarmActionが未設定のアラーム（5個） Case#2 ActionのSNSトピックが存在しないアラーム（16個） Actionを差し替えるのはちょっと手間 Case#3 ActionのSNSトピックの通知先が退職した社員のメールアドレス（97個） Case#4 監視先のDynamoDBのテーブルがすでに存在しないアラーム（97個中の85個） Case#5 監視先のE
REST API 設計指針・セキュリティ編
過去2回の記事でREST API 設計指針をまとめてきました。 REST API 設計指針・認証認可編 REST API 設計指針・通信、パラメーター編 今日は第三回かつ最終回のセキュリティ編です。セキュリティは非常に幅広い概念であり、考慮すべきことは山盛りですが、まずは基本的な考え方から。 加害者と被害者の逆転現象 悪意のある第三者からの攻撃などにより何某かのインシデントが発生して、サービスが停止したり、情報漏洩が起きてしまった場合、サービス事業者はステークホルダーにお詫び、時には直接的な金額による賠償を行うことになります。本来システムを攻撃された被害者側ですが、加害者であるかのような扱いをされるケースがあります。一方インシデントの種別によっては世の中が同情的になるケースもあります。この違いについてですが、一般的によく用いられる対策をとっていたかどうかが大きな分岐点となります。 攻撃され
Active Recordともっと仲良くなって自然に優しいコードを書くぞ - SmartHR Tech Blog
こんにちは。SmartHRでRails顧問業をしています @willnetです。最近は主にリファクタリングをしています。 SmartHRのバックエンドは基本的にRubyで書かれています。しかし入社してくるバックエンドエンジニアは必ずしもRubyやRailsを長年使ってきた人だけではなく、前職では他言語を使っていてRuby(Rails)はほとんど使ったことがないという人もいます。 webアプリケーションを作る、という点ではどの言語でも抑えるべき点は同じですが、RubyやRailsに特化した考え方や書き方もありますよね。SmartHRではそれを効率よく習得してもらうために読書会を開催したり、社内のドキュメントツールに知見を書いて共有したりしています。 僕も社内のドキュメントツールにActive Recordの付き合い方ついて書いたところ、評判が良く「テックブログにしたら？」と言われたので今回一
こんにちは、インフラ部の id:sue445 です。私事ですが先日GCPの Professional Cloud Architect を取得しました。 そういうわけで今日はGCPではなくAWSの話をします。 tl;dr; 劇的ビフォーアフター 構成 移行のモチベーション パフォーマンス向上 コスト圧縮 アーキテクチャの採択理由 やったこと 1. DB作成 2. MySQL 5.7 -> 8.0 MySQL 8.0でハマったこと MySQL 8.0からデフォルトの認証がcaching_sha2_passwordになった RDSのMySQL 8.0からMariaDB 監査プラグインがなくなった 3. 本番用のDockerイメージを作成 困ったこと：CodeIgniterがログの標準出力に対応していなかった 4. ECS + Fargate + CodePipeline構築 5. CDN作成 6
ログ分析勉強会は、日々の業務に役立てられる「ログ分析」についての情報交換を目的として活動しています。オンライン開催となった今回、AWSに詳しい山口氏がWebサービスのパフォーマンス改善に必要なログ分析について、日々の業務から得た知見を共有しました。後半は、サーバーサイドから見たログ分析について。 サーバ情報を可視化して負荷状況を見る続いて、サーバの負荷状況を見るところですね。リソースの情報をコマンドで取得してサーバ情報を可視化しましょうというところです。 よく使うのは、1つ目はhtopですね。htopでプロセスごとにどれくらいのメモリやCPUを使っているかを取っていくのがあります。リクエストが多いときにこれを取っていって、どこが重たくなっているかを見るというのがいいかなと思っています。 例えばアプリケーションサーバと同梱されているものだったりとかすると、アプリケーションサーバの負荷がいきな
New Relic Now Start training on Intelligent Observability February 25th.
大規模システムにおける5つのログ転送パターン
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
オブザーバビリティには限りがない話
先日NewRelicの清水さんにマンツーマンでオブザーバビリティの話をきかせてもらえるという貴重な経験をした。長年アプリケーションレイヤーも含んでシステム運用の経験があると「あるある」な話なのだが、次のようなことが起こる。 何か不具合や障害が起こる 該当時刻のエラーログなどを見るが情報が少なく、原因を特定する決定打に欠ける 次回、また同じことが起こったときには原因を特定できるように、printfデバッグするコードを大量に埋め込んだバージョンに更新して、デプロイする もう一度起こるのを待つ これは最初の状態が「オブザーバビリティに欠けた状態」だったと言える。めちゃ納得してEnter Sandmanくらいヘドバンして頷いてしまう。 僕の経験上このようなケースを避けるために良い結果を出してきたのは、Javaの例外が出た箇所でスタックトレースを取得しておくことだ（僕らは単にログファイルに吐いておい
GitHub Actionsを可視化するGitHub Actions OpenTelemetryの紹介 - Paper2 Blog
GitHub Actionsはワークフロー全体の実行時間や各ステップの詳細な可視化、変更による効果測定を行うには工夫が必要となります。この記事では、OpenTelemetryを活用してGitHub Actionsの実行結果をトレースとメトリクスの形で収集するGitHub Actions OpenTelemetryを紹介します。どのステップに時間がかかっているのか、改善施策の効果がどの程度あったのかを把握しやすくなるため、ワークフローの継続的な改善を目指す方に役立ちます。 Trace Sample (Jaeger) 1. GitHub Actionsにおける課題 1-1. ワークフローの詳細を可視化する方法が提供されていない 1-2. ワークフローの変更による影響を分析しづらい 2. GitHub Actions OpenTelemetryとは 2-1. 概要と主な機能 2-2. OpenT
DB は以下のコマンドで確認できる通り、MariaDB 10.3 でした。$ mysqld --version mysqld Ver 10.3.31-MariaDB-0ubuntu0.20.04.1 for debian-linux-gnu on x86_64 (Ubuntu 20.04) 当日マニュアルに記載の通り、各言語実装は systemd で管理されているため、systemd に関する知識があると良いと思います。特に、アプリケーションを編集しビルドした後、 systemctl restart isucondition.go.service を実行しないと編集が反映されないことに注意しましょう。 他にも例えば、isucondition がどのように環境変数を読み込んでいるかを調べるには以下のような手順で行えます。 当日マニュアルの参考実装の項目を読み、サービス名が isucondit
「北欧、暮らしの道具店」インフラ構成の変遷、5年間の課題と取り組み｜Kurashicom Tech Blog
こんにちは。エンジニアの佐々木です。 先日12/6、弊社イベントにてカヤックの藤原さんを交えてクラシコムのSREについてお話をさせていただきました。 当日は96名と多くの方にお申し込みいただきありがとうございました。1時間半があっという間で、時間の関係でお話できなかったことも多々ありました。改めてではありますが、記事にて当日の内容含め話せなかったこともご紹介したいと思います。 当日のテーマは「インフラ強化に向けた具体的な取り組み」と「一人に頼らないチーム体制づくりを目指して」という2つでした。 この記事では前半の「インフラ強化に向けた具体的な取り組み」について紹介します。北欧、暮らしの道具店のインフラ構成の変遷を追いつつ、その時々の課題や実際の取組みについて説明していきます。 5年前(2017年5月頃)のインフラ構成エンジニア3人で作った月間1600万PVのECサイト 「北欧、暮らしの道具
フロントエンド監視の全体像と実現方法
必要性 フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。 バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。 それは計算リソースをサービス提供側が管理していないことです。 例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。 これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。 一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。 フロントエンドはその性質上、監視の「盲点」になりがちです。 しかしフロントエンドはエンドユーザが直接触れるものであるため、そこで何が起きているかサービス提供側は正確に把握する必要があります。 マイルストーン フロント
[書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO
こんにちは、臼田です。 みなさん、よりよい運用してますか？(挨拶 今回は2021年9月15日に発売された書籍「New Relic 実践入門 監視からオブザーバビリティへの変革」の書評です。オブザーバビリティ(可観測性)について概念的にも実践的にもわかりやすい図とともに理解でき、特にNew Relicを活用して、単純な監視ではない、ビジネスに貢献するための運用の実践ができる一冊でした。 この記事ではこの書籍を読んで感じた、どんな人に向いているか、特に良かったところなどを書いていきます。 どんな人に向いているか 一言でいうと、「これからNew Relicを触る人、あるいは触り始めた人が活用できる書籍」です。「New Relic実践入門」というタイトルそのままですね。 逆に言えば、関連するオブザーバビリティについて理解を深めたい、あるいはNew Relicに限らない監視や運用の考え方を学びたいだ
![[書評]「New Relic 実践入門 監視からオブザーバビリティへの変革」は可観測性を学び実践するための一冊 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/8c4a671f0383ff1209fc2471ae109869a83c8ad9/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F10%2Fnewrelic_review.jpg)
監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability
2023/5/23開催「オブザーバビリティ最前線 〜 事例LTから学ぶ、オブザーバビリティの成熟度〜」
SREチームがNew Relicを使って AWSコスト最適化に貢献した話 株式会社ニューズピックス 安藤 裕紀 NRUG (New Relic User Group) SRE支部 Vol.3 - 2023.6.27(Tue)
Infrastructure as Codeに関する技術書籍を執筆しました - How elegant the tech world is...!
Overview タイトルの通りですが、技術書博5向けにInfrastructure as Code (IaC)に関する技術書を執筆しました。 gishohaku.dev 一応、僕がそれなりにAWS x IaCにどっぷり浸かっていることもあり、題材のクラウドはAWSを主軸にしています。 TerraformやPulumiに関しては、別にAWSに限らずAzureやGoogleCloud利用者の方々にも通ずる部分があると思います。 執筆に至ったモチベーション 僕自身、IaCサービスに関してはCloudFormation 数ヵ月、terraform 2年、Pulumi 8ヶ月ほど経験しており、 それぞれの特徴も知れてきたのでナレッジを形にしたいなと思い、同僚と執筆しました。 ※ちなみに、共著の同僚である@HorseVictoryはAWS Top Engineersの一人です。 クラウドネイティブな
株式会社MIXIで『家族アルバム みてね』（以下みてね）のSREグループに所属している本間です。 みてねは現在、1,500万人を超えるユーザに175の国と地域でサービスを提供しています(2022年8月現在)。そこで、より高い信頼性と可用性を担保するためにみてねのSREグループではオンコールエンジニア制度を設けています。 今回はこの「みてねのSREグループにおけるオンコールエンジニア制度の取り組み」についてご紹介させて頂きます。 オンコールの定義 まず、どのような条件でアラートを設定しオンコールを実施するかの定義について簡単に触れておきます。 現在はさまざまなソースから多種多様な情報を収集することができます。 たとえば、みてねではKubernetes（Amazon EKS）を採用しています。Kubernetesだけでも非常に多くのメトリクスが収集できますが、それだけではなくアプリケーション
はじめまして、Progateの村山です。 本記事はProgateAdventCalendarの2日目の記事です。 普段はSREチームでProgateの開発や運用を支える仕事をしております。Progateには今年の7月に入社しました。前職はElixirやk8sなどを使ったWebアプリケーションの開発や運用をしていました。ProgateにElixirのコースを作るのがちょっとした野望です。 本稿ではサービスや開発のモニタリングについて紹介しようと思います。 モニタリングとは モニタリングは日本語で監視と言い、主にサービスの障害検知や可用性向上のために利用されています。ここで紹介するモニタリングは大きく2種類に分類したいと思います。 1つ目は死活監視するためのモニタリングで、サービスやアプリケーションの可用性監視し、必要に応じてフェイルオーバーさせたりアラートを飛ばして開発者へと共有します。 2
OpenTelemetry を利用して PHP アプリケーションのテレメトリデータを計装する方法をまとめました。 本エントリのコードは下記で公開しています。 github.com OpenTelemetry とは 用語 PHP アプリケーションのマニュアル計装（手動計装） 構成 OTel Collector Jaeger 動作環境 必要なパッケージ PHP コード 設定 実行 PHP アプリケーションのゼロコード計装（自動計装） 必要な拡張とパッケージ 設定 PHP コード 実行 さいごに 参照 OpenTelemetry とは opentelemetry.io OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ（トレース、メトリクス、ログなど）を計装、生成、収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、CNC
おまたせしました この度、ついにこの記事を完成させることができました。これは私が数年前からずっと書きたいと思っていた、ウェブのアクセスログに対する、機械学習を使った異常検知の実例です。私は事あるごとに(※1)「情報セキュリティ分野でもデータサイエンスの技術は非常に重要だ」と繰り返していますが、この記事の内容はまさにその1つの証となると思います。この記事で示される内容を見れば、「うわ、機械学習、マジでヤバイい(語彙力)んだな...」となるでしょう。以下に心当たりのあるセキュリティエンジニアはぜひ読んで、そして実践してみてください。 機械学習に興味はあるものの、どこから手を付ければよいのかイメージがわかない 本当にAIやデータサイエンス、機械学習がセキュリティの分野で役に立つのか、確信がもてない データサイエンスや機械学習は難しそうだと思っている ログ解析において、grepや単純な統計処理より
インデックスの"正解"を探せ！決済レスポンスタイムを改善したパフォーマンスチューニング - inSmartBank
はじめに サーバーサイドエンジニアの kurisu(ryomak) です。 普段は、カード決済やあとばらいチャージに関連する機能の開発・運用を行っております。 本記事でお話しすること 本記事では、インデックス追加によって決済レスポンスタイムを改善した事例をご紹介します。具体的なインデックス設計の検討や実行計画の見直しを通じて、どのようにレスポンスタイムを最適化したのか、その裏側を詳しく解説します。インデックス追加によるパフォーマンスチューニングの際の参考になれば幸いです。 はじめに 本記事でお話しすること 決済処理の遅延の検知 事の発端 実行環境 原因調査 遅くなったクエリの特定 対応検討 方針 検証項目 インデックスの「アタリ」をつける ① オーソリゼーション履歴：(オーソリゼーションID, 承認番号,受信日時) ② オーソリゼーション：(カードID, 初回受信日時) ③ オーソリゼーシ
荒廃したテックブログの再生
これは『2023年度を数字で振り返る「技術広報LT大会」』の登壇内容について、 口頭で話したことを補足しつつ、その他話せなかったこと含めてドキュメントにまとめたものです。 LT大会は楽しいですね、各社の発表も有益情報が多かったので、また行こうと思います。 TL;DR テックブログの投稿本数が94倍、PV数が39倍に。 まずは、定石に則りアンチパターンを潰す。 自社の風土に合わせてローカライズしてアウトプットを継続する工夫を。 書きたいものを書いてもらった上で、「できる限り読まれる努力」は運営の責任。 当ドキュメントは色々私が書いてますが、全て編集長がやったことです。 荒廃したテックブログの再生 荒廃してました！ レバテック開発部としては、年2本しかテックブログを書いていませんでした。 荒廃の定義にもよりますが、私はこれを荒廃と見てました。 技術広報を促進していくタイミングで、まずはここから
概要 全般 何はともあれコストタグ Cost Explorer でリソース別にコストを見よう IaC化しよう QuickSight も使おう 稼働時間対応する際はマスタカレンダを用意したい コンピューティング、コンテナ関連 EC2 定時バッチはマネージド化しよう EBS, Snapshot, AMI, EIP を消す ECS Container Insights の有効/無効を使い分けよう 何でも Fargate を選択すれば良いわけではない Fargate スポットを活用しよう Lambda Graviton対応しよう ECR イメージサイズを抑えよう ライフサイクルポリシーを設定しよう ネットワーキング VPC VPCエンドポイント入れ忘れに注意 VPC Flow Logs のS3バケット設定に注意しよう ストレージ系 RDS スロークエリ出てないかAPMを使って確認 DynamoDB
久々に溜まったブログネタ放出をしようかなと、その前に下書きから掘り起こしてきた、いまさらなスロークエリ関連で準備運動です。 RDSのスロークエリ情報は当然、集計を自動化していつでも見れるようにしてあるのですが、ちょいと必要があったので、今回はあえて単発ログを集計する形に切り出したものを用意してみました。 スロークエリログの必要性 最近はNewRelicとかで、アプリケーションの処理を分別して処理時間などを集計するので、それで課題となるクエリを確認したりもします。 非常に便利な仕組みですが、アプリケーション外のジョブなどが実行したクエリは集計されないことや、負荷試験で課題を炙り出すときだとテスト環境にエージェントやライブラリを仕込む必要がある、といったデメリットとまでは言わないまでも面倒さがあります。 その点、スロークエリはサーバー側で記録するものなので、0.1秒とかでONにしておけば、対象
オブザーバビリティ（可観測性）とは何か？を学べる「Distributed Systems Observability」を読んだ - kakakakakku blog
2019年頃から「オブザーバビリティ (Observability)」もしくは「可観測性」という言葉をよく聞くようになった（本記事では「オブザーバビリティ」という表記に統一する）．「マイクロサービス」と同じように「バズワード」の側面があり「オブザーバビリティとは何か？」という質問に対して様々な回答が考えられると思う． 今回は「オブザーバビリティ」の理解を深めるために「Distributed Systems Observability」を読んだ．本書は O'Reilly Media で読むこともできるけど，Humio のサイトから無料でダウンロードすることもできる（メールアドレス登録は必要）．著者は Cindy Sridharan となり，肩書は「Distributed Systems Engineer」と書いてあった． www.humio.com 目次 本書には「オブザーバビリティ」をテー
導入 本記事では以下を記載します。 「VPCとAWSサービス間の接続」や「VPCと外部との接続(PrivateLink使用可能)」において、 VPCエンドポイントを使用するべきか、もしくはNAT Gatewayを使用するべきかを セキュリティ面と費用面から比較してみます。 セキュリティ面 VPCエンドポイント VPCエンドポイントを使用すると、VPCとAWSサービス間の通信をインターネットを経由せずに直接接続することができます。 最近はVPCエンドポイントを用いて接続できるSaaSも増えてきています。 外形監視のNew Relicも一部リージョンでPrivateLinkによるサービスが開始されました(※東京リージョンは対象外)。 https://docs.newrelic.com/jp/docs/data-apis/custom-data/aws-privatelink/ PrivateL
翻訳を担当した電子書籍『Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。 Ruby on Rails パフォーマンスアポクリファ 本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。 The Ruby on Rails Performance Apocrypha The Ruby on Rails Performance Apocrypha: A starter guide to making Rails apps faster and more scalable (English Edition) 作者:Berkope
はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画
オブザーバビリティ導入の教科書〜「投資対効果は？」に負けないオブザーバビリティの導入方法〜 - Findy Tools
公開日 2024/11/12更新日 2024/11/14オブザーバビリティ導入の教科書〜「投資対効果は？」に負けないオブザーバビリティの導入方法〜 システムから出力されるあらゆる情報を計測し、システム内部の状態が常に観測・制御可能な状態を指す「オブザーバビリティ」。開発生産性の向上のほか、顧客満足度の向上や事業成長への貢献にもつながるとあって、近年注目を集めています。しかし、その重要性は理解していても、社内での導入や浸透となると難しいもの。特に、現状の監視体制で十分だと考える経営陣を説得し、新たなツール導入や体制構築に向けて動き出すのは簡単なことではありません。 そこでFindy Toolsでは、オブザーバビリティプラットフォームを提供するNew Relicの上席エヴァンジェリストの清水氏へインタビューを実施。オブザーバビリティの価値、New Relicの独自の強み、そして導入による事業貢
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Webアプリ負荷試験ガイド - withgod's blog
データベース設計の際に気をつけていること - 食べチョク開発者ブログ
とりあえずWebサービス作る時の私の技術選定ポイント@2022/02
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
副業×AWSでわりと人生変わったエンジニアの話 - Qiita
決済基盤のアーキテクチャ特集 - Findy Tools
Herokuから ECSに 移行した - pixiv inside
Webサービスエンジニアが教えるサーバサイドのログ分析 情報を可視化して負荷状況を見よ | ログミーBusiness
Javaの現状：世界で最も人気のあるプログラミング言語の一つであるJavaの動向とデータ
ISUCON11 予選問題実践攻略法 : ISUCON公式Blog
SREチームがNew Relicを使って AWSコスト最適化に貢献した話 | ドクセル
『家族アルバム みてね』を支えるオンコールエンジニア制度 | gihyo.jp
Dockerで動かして学ぶモニタリングの基礎 - Progate Tech Blog
PHP アプリケーションのトレース計装ではじめる OpenTelemetry 入門 - Shin x Blog
本物のウェブアクセスログを使用した、機械学習による異常検知(全データ/ソースコード公開)
2023年のSREチームのAWSコスト削減を振り返る - Uzabase for Engineers
PythonでMySQLのスロークエリログを集計 | 外道父の匠
VPCエンドポイントとNAT Gatewayの比較 | iret.media
『Ruby on Railsパフォーマンスアポクリファ』 - snoozer05's blog
Datadog→New Relicの移行を決めた際のADRを公開します！