ID:70666さん

# 目的 マイクロサービス化を進める中で、最後に残ってしまったRedisを分割しました # 規模と担当範囲 クラスタのメモリ量は1TB以上、ノード数は50以上、担当範囲は設計から実行まで主に一人で行っています。（コードレビューや移行方法のレビューはチームで確認しています） # 移行方法 まずアプリケーションコードを読み、どのような用途で利用されているかを洗い出しました。そして分割の粒度を決め、チーム内で合意を取りました。そのあとはrdbファイルを解析し、必要なRedisのサイジングをしました。 その後、デュアルライトするロジックやkafkaを用いたEDAに変更することによって、データを徐々に移行して無事完了しました。 # 取り組みの成果 移行のついでに様々なチューニングやバージョンアップも行い、サイジングも適切に行ったため、コストとパフォーマンスの両面で大きな改善が出来ました。

＃プロジェクト概要 担当プロダクトでは、年に一回、通常時の10倍以上のスパイクアクセスが来るタイミングがあります。ビジネス的にも非常に重要な期間なため、このための準備に毎年約2ヶ月ほどの期間を使っています。 私が担当したプロジェクトでは、その年のスパイクアクセスを安定して処理することはもちろん、来年以降のプロジェクト進行の標準化（テックリード以外でも出来るように）を行いました。 ＃チーム情報 SREとして私が主に企画からタスクマネジメントを行いつつ、人海戦術で解決するべき部分は適切に他エンジニアに協力を仰ぎました。 ＃アクセス数の見積もりを行う 【概要】 スパイクアクセスの見積もり方法の提案および実施 【課題・問題点】 従来、アクセス見積もりはベテランエンジニアによる熟練の技のようになっており、プロジェクト担当者によって精度が不安定でした。 【打ち手・使用した技術】 複数の統計予測手法を組み合わせ、それぞれの予測値が近しい値であれば、精度が高い見積もりと見做すように見積もり方法を標準化しました。 また予測値同士の分散が大きい、つまり精度の低い見積もりに対して、安全マージンを多く盛るといった対策も標準化しました。 ＃処理性能を分析する 【概要】 一年間に行われたコードの変更などにより、既存アプリケーションのボトルネックや処理可能アクセス数が変わっている可能性があります。この点を明らかにする必要があります。 【課題・問題点】 アクセス増が予想される20以上のマイクロサービスに対して、限られたエンジニアリソースでボトルネックや処理できるアクセス数を確認する必要がありました。 【打ち手・使用した技術】 実際にユーザーリクエストを処理している本番環境において、アクセスを特定サーバーに集中させて、意図的に高負荷状態を発生させるカオスエンジニアリングを行いました。 また想定より低い処理性能しか出ないアプリケーションでは、CPUプロファイラなどを活用して、アプリケーション内部のどの処理にコストがかかっているか確認してチューニングも行いました。 # 過負荷の発生を前提とした準備をする 【概要】 どこまで予防策を行っても、どうしても防ぎきれないものが障害です。そのため、障害発生を前提とした軽減および緩和策を準備する必要があります。 【打ち手・使用した技術】 企画、サーバーサイドエンジニア、クライアントサイドエンジニア、QAエンジニア、SREなどを招集し、開発環境でAPIを一つずつエラーにするFault Injectionのワークショップを企画しました。 これによって、クライアントサイドのエラーハンドリングの改善事項を明らかに出来たり、企画担当者視点でどの機能がビジネス的に重要かを確認することができ、その機能を生かすために他の機能を落とすといったGraceful Degradationの議論が出来ました。 また、これらの私が行った進行方法を標準化し、今ではSREによるリードは最小限になり、開発チームで行える範囲も広がっています。

＃プロジェクト概要 開発者にとって馴染みのないツールを新規導入する際に、どうしても反発であったり、特定の人物のみに知見が集中してしまう問題があり、その解消のためのEnablIngを実施しました。 ＃チーム情報 開発者20名程度、SRE私一人 ＃Weekly 20 minutes hands-on 【概要】 新たなツールについてハンズオンセッションを企画して実施することはよくあるのですが、その実施方法を毎週20分の定期ハンズオンとしました。 【課題・問題点】 1時間以上のハンズオンセッションの場合、準備にコストがかかる他、なんらかの想定外によって脱落者（当日不参加なども含む）が発生することがあります。 【打ち手・使用した技術】 毎週20分の定期ハンズオンを実施し、TerraformやKubernetesやGithub actionsについて、開発者向けの勉強会を開催しました。 20分の勉強会の準備は2-3時間程度で出来ますし、脱落者が出ても翌週の勉強会までに個別にフォローすることで、チームで新しいツールに対しての反発も少なく、知見を習得することが出来ました。