Datadog→New Relicの移行を決めた際のADRを公開します！
はじめに レバテック開発部、SREチームに所属している金澤です。 弊社開発部では、Datadogで行っていた監視からNewrelicを用いたオブザーバビリティへの移行を行う決定をしました。 そして、なぜオブザーバビリティを採用したのか、DatadogからNewrelicへ移行したのかといった意思決定をADRとして記録し、社内に展開しています。 今回はこのADRの内容を公開します！ ※本記事はNewrelic、Datadogを肯定、否定するものではございません。 ADR コンテキスト 事業軸 レバテックの事業戦略は事業ポートフォリオ構想に従っている 既存の事業を拡大させながら新規サービスを生み出し続ける 事業ポートフォリオ構想 開発軸 事業領域の大きさ、深さが拡大し必要なドメイン知識が肥大化 スケーラビリティとアジリティの担保が困難になってきた バグ、障害の発生 レビュー工数の増加 新規参画
俺はDMARC認証の対策をしたと思ったら、いつの間にか他社のDMARCレポートに引っかかっていた
あ…ありのまま今起こったことを話すぜ！ はじめに どうも、レバテックでCREをやっている住村です。 去年から飼い始めた犬が先日1歳の誕生日を迎えて、「もう1歳か」と「まだそれくらいしか経ってないのか」という矛盾した感覚を覚えます。 世のお父さんお母さんたちもこういう感覚なんでしょうか？ 先日、Gmailの送信ガイドラインの変更で各社でもList-Unsubscribeヘッダの対応に追われたり、自社ドメインのDMARC認証状況を確認するためにDMARCレポートを見るようになったりで様々な対応を迫られていると思います。 関連して、今回は自社のメーリングリストが他社のDMARCレポートで認証失敗として検知されたので、その対応で得た知見を書こうと思います。 概要 メーリングリストなどによるメールの転送時、DMARC認証に失敗することがある メール転送時にエンベロープFromが書き換わり、ヘッダFr
スロークエリを改善したらECSの負荷が爆下がりした話(TypeORM)
TL;DR TypeORMで発生していたスロークエリを改善 スロークエリを改善したらECSの負荷も減少 はじめに スロークエリを改善したら、ECSコンテナ側の負荷も下がってなんでだろ？と思ったので記事にしようと思います。 環境 TypeORM v0.3.20 Node.js v18.x バックエンドインフラ ECS on Fargate => Amazon Aurora MySQL 負荷改善の前と後 まずはどのくらい改善したのかを示します。 この時ECSコンテナ8台動いてました。(4vCPU 8GBMem) 改善前 改善後 改善前と改善後は一日前の同じ時間帯のものです。 ちゃんと動いてるのか不安になるくらい下がってました笑 どのような対応をしたのか スロークエリの出ていたクエリでMySQLの実行計画を確認しました。 TypeALL,index, Using Filesort等はなかったので
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
