ワーキンググループを通してバッチサーバのリプレースを行ったこと - Retty Tech Blog
Retty インフラチームの中西です。 今回は バッチサーバのリプレースを行ったお話になります。 バッチサーバについて 課題について 1. EC2-Classic からの脱却 2. セキュリティ 3. ログ管理 4. バッチについての管理、情報がない 課題に対する対応 1. EC2-Classic からの脱却 2. セキュリティ 3. ログ管理 4. バッチについての管理、情報がない 振り返りについて 良かったこと 苦労したこと まとめ バッチサーバについて Rettyのサービス黎明期から存在しているサーバでEC2インスタンスとなります。 (EC2-Classic で起動していた事から歴史を感じるサーバとなっています) バッチとしてはそれぞれ crontab に登録をして.データの整備や集計処理を行っています。 このサーバには課題が多々含まれており、インフラ、開発からの有志としてチームを組
モノリシックなRailsアプリケーションで、APIのエンドポイント毎にSLOを設定する - Repro Tech Blog
こんにちは、@r_takaishiです。今回は、モノリシックなRailsアプリケーションが提供するAPIについてエンドポイント毎にSLOを設定できるようにしたので紹介します。 解決したい問題 ReproではRailsアプリケーションが様々なAPIを提供しています。このとき、APIのAvailabilityやLatencyについて可視化して障害が起こっていないか、パフォーマンスが低下していないかを調べることがあります。また、APIについてSLOを設定し、サービスの信頼性を保ちつつ開発を行うこともあるでしょう。 Reproでも可視化やSLOの設定は行ってきました。しかし、それらの対象がALBのTargetGroup単位だったり、APIを提供するECS Service単位でした。このような単位だと、API全体についての状況は分かりますが、個々のAPIについての情報は得られません。例えばエンドポイ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
祝 🎉 両方とも正式リリース！ GitHub Codespaces と Nuxt3 で次世代開発体験 / codespaces-nuxt3
