AWS JDBC Driver の Failover Plugin を使って3秒でAurora DB ClusterのWriterをフェイルオーバーしてみた | DevelopersIO
Amazon Auroraのフェイルオーバー時間を短くしたい こんにちは、のんピ(@non____97)です。 皆さんはAmazon Auroraのフェイルオーバー時間を短くしたいなと思ったことはありますか? 私はあります。 Auroraのフェイルオーバー時間は60秒未満と言われています。しかし、「60秒では長すぎる。せめて10秒程度でフェイルオーバーは完了させたい。」といったこともあると思います。 フェイルオーバー時間を短くする方法はクライアント側でMariaDB Connector/JやPostgreSQL JDBC Driverなどのドライバーを使用したり、RDS ProxyやProxySQLなどプロキシを挟むパターンがあります。 他にもフェイルオーバー時間を短くする方法が何かないかと探しているとAWS公式ドキュメントにフェイルオーバー時間を短くするための方法がまとまっていました。
「ホットペッパービューティー」美容クリニックでのSRE活動
美容クリニックは新規体制用の少人数体制で開発を行っており、その内の約 7 割がアプリ開発をしているエンジニアとなっています。 一方で、SRE は全体の約 1 割の人数しかいないという状況にあります。 この SRE の人数が少ないかどうかは扱っているシステムの規模や課題によって評価が変わるかと思いますが、美容クリニックが現在抱えている課題の量に対しては少ない人数だと感じています。 では、このように限られた人数の中でどのようにして SRE 活動を行ってきたのかを紹介していきます。 SRE チームの組閣 美容クリニックのリリース以前から SRE チームは存在していたのですが、リリース前後でその責務は変わってきます。 例えばリリース前はインフラの初期構築がメインの責務となってきますが、リリース後（エンハンス開発）にはインフラの保守運用がメインの責務となります。 さらに、メンバーの変動などにより当初
SRE チームをよりサステナブルにするために Vision/Mission/Values を作った話 - スタディサプリ Product Team Blog
小中高 SRE チームで Engineering Manager をやっている @yuya-takeyama です。 Quipper にはスタディサプリ ENGLISH の SRE である ENGLISH SRE チームと合わせて 2 つの SRE チームがありますが、この記事では自分たち小中高 SRE チームについての話です。 少し前の話になるんですが、小中高 SRE チームの Vision, Mission, Values というものをチームで作りました。 Quipper には会社としての Vision, Mission そして Quipper Identities というものがあります。 これらは策定から数年以上経っていますが、Quipper の社員にとって今も変わらず大事なものです。 が、SRE チームにとっては教育や学習に対して直接的に貢献しているとは言いづらい状況です。 そこで
「6社合同 SRE勉強会」で学んだこと
以下イベントを見てたときのメモ的なあれです。SREの初学者目線で学べたことを書きました。全ては見れてません。 全体通して学んだこと 「SREとは」といったところから定義しているところが多かった こうしないとインフラエンジニアの名称が変わっただけのただの便利屋になってしまう 何ができて何をするのか https://blog.studysapuri.jp/entry/sre-vision-mission-values SREはSREでも種類があったりした CenterOfPractice(CoreSRE、pureSRE、横断SREなど) 全社としてのSRE ベストプラクティスの策定 ツールの選定や開発 EmbeddedSRE プロダクト開発チーム内としてのSRE Embeddedだと外から埋め込むという意味合いになってしまうので、内部からの場合はenablingといった表現をしている会社もあっ
コードレビューでコメントタグを使い、心理的安全性を担保しよう
こんにちは。リンクウェル対面診療システムチーム、テックリードの山本です。 今回はコードレビュー時に開発部で実施しているコメントタグのご紹介です。 多分イケてる開発チームではすでに取り組んでいる試みだとは思いつつも、今回はなぜ必要なのかを改めて考えてみたいと思います。 GitHubのプルリクレビューについて 弊社のコードレビューではまず第一に「要求を満たすよう動くこと」が重視されます。その上で次のような点に注視しながら指摘を行います。 外部サービスの特殊な挙動やセキュリティ機構などが考慮されているか。 不具合が発生した時に検知できるようになっているか。 将来的に修正しづらくなる構造になっていないか。 N+1問題などパフォーマンスに問題がないか。 その上でコメントを書く際に次のようにタグを付けて分類しています。 must: 絶対に直して欲しいとき。強い指摘になるので言葉遣いに気をつけるべき i
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
