Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Embedded SREと共に達成した会員管理システムのAWS移行 - SRE NEXT 20...

Embedded SREと共に達成した会員管理システムのAWS移行 - SRE NEXT 2026 ランチスポンサーセッション

イベント
SRE NEXT 2026
https://sre-next.dev/2026/

登壇者
ニフティ株式会社
西原 俊輔

More Decks by ニフティ株式会社

Other Decks in Programming

Transcript

  1. Copyright © NIFTY Corporation All Rights Reserved. 2 ⻄原 俊輔

    (Nishihara Shunsuke) ニフティ株式会社所属。2007年新卒⼊社。 会員基盤系システムのバックエンドエンジニア。 社内スペシャリスト制度「N1!」のIDアーキテクト 現在は「次期会員基盤」プロジェクトの推進を担当。 SREについてはあまりに知⾒がない。 趣味はスティールパンとトランペット。 @shun_nishi ⾃⼰紹介 N1!IDアーキテクト
  2. 1986年の創業以来、⽇本のネットワーク⽂化を牽引。現在はノジマ チームの⼀員として、 ISP事業を起点として、幅広いサービスを展開しています。 私たちの使命は、130万⼈の⽇常を⽀える巨⼤な基盤を⾃ら「モダン化・内製化」し、技術 の⼒でお客様に「いいこと」を届け続けること。35年以上の歴史を持つニフティだからこ そ、社会的インパクトの⼤きい技術的挑戦が可能です。 「ニフティとなにかいいこと、」をテクノロジーで体現し、 お客様に最も近いISPへ。 沿⾰ 130万⼈の会員基盤を⽀える、国内有数のインフラ。

    その安定した⼟台を、エンジニアの⼒で次世代へと進化させる ノジマ チームに参画 2017年 WEBサービス事業の⼀部である マーケットプレイスサービスを承 継した「ニフティライフスタイル 株式会社」が事業を開始 2018年 ポイントサービス 「ニフティポイントクラブ」・ 会員向けアプリ「マイ ニフティ」 提供開始 2021年 「@nifty光 10ギガ」 提供開始 2023年 品川オフィスへ移転し ノジマ チームの シナジー強化 2026年 3
  3. 1 2 3 「つなぐ」の先にある、新しい当たり前を創る。 ⾼速で安定したインターネット接続を提供し、 快適なデジタルライフの基盤を⽀えます。 ニフティの事業と組織⽂化 ISP 通信からWebサービスまで、 ⼈々の⽣活を総合的に⽀える事業展開

    オプション Web お客様が安全・安⼼して利⽤できるよう、 セキュリティやサポート体制を万全に 整えています。 情報収集から⼦供向けの安全な遊び場まで、 多様なニーズに応えるコンテンツを 提供しています。 4
  4. ニフティの事業と組織⽂化 ニフティのすべてのお客様のIDの発⾏と管理をし ているシステムで、⼤規模なRDBMSと数多くの APIとバッチによって構成されています。 システム利⽤者は各サービス担当者だけでなく、カ スタマーサポートや社内システムも含まれており、 全社員が関わっているシステムといっても過⾔では ないです。 内製化プロダクトの紹介 会員基盤

    システム概要 これまでのニフティの歴史とともに歩んできたシステ ムです。接続会員130万⼈を含む、500万⼈会員のお 客様の情報を管理しています。古くから動いているシ ステムではありますが改修やリプレースを繰り返し現 在ではAWS上で稼働し、ECS FargateやRDSといった モダンな構成で構築されています。 プロダクトの魅⼒ カスタマーセンター向けサポートツール ニフティのサービスをご利⽤いただくお客様向けの 「マイページ」と、コールセンターで働くスタッフ が利⽤する「社内サポートシステム」の設計・開発 ・運⽤を⾏っています。 顧客サポートを完全内製化している環境で、フロン トエンドからバックエンド、インフラ、さらには電 話のクラウドPBX導⼊まで、幅広い技術領域に携 わっています。 システム概要 ⽉間約数万件の受電があるコールセンター内に拠点 を構え、現場密着型の開発を⾏っているのが最⼤の 強みです。スタッフの要望をスピーディに反映でき る裁量と環境があります。モダンなパブリッククラ ウド環境や⾃動化された開発基盤を活⽤し、電話の ⾃動応対など顧客サポートへのAI技術の社会実装 も強⼒に推進しています。 プロダクトの魅⼒ 6
  5. Copyright © NIFTY Corporation All Rights Reserved. 8 • 限られた期間の⼤規模移⾏プロジェクトの中でもIaCやモニタリングを

    導⼊することができた Embedded SREを受け⼊れてよかった! • プロジェクト内のどの範囲をSREに担ってもらうかを決めることが⼤事 • SREが作ったリソースを負債にしないためにはプロジェクト期間中の定期的な 対⾯レビューと対話が不可⽋ TL;DR
  6. Copyright © NIFTY Corporation All Rights Reserved. 10 アプリケーション構成 Apache

    Tomcat PostgreSQL 規模と可⽤性 500万IDのデータを管理 API 200本 / バッチ 150個 フロントエンドはなし 社内のほぼ全サービスが 使っているため停⽌は困難 主要機能 • ID登録 • ステータス変更 • 決済情報の管理 • 認証認可 など、会員のライフサイ クル全般 会員管理システムの役割と構成
  7. Copyright © NIFTY Corporation All Rights Reserved. 11 次期会員基盤 フェーズ1

    フェーズ2 フェーズ3 ※フェーズ1の 構成廃止 現会員基盤を ほぼそのままAWSへ移行 クラウドネイティブな 状態を実現 一部機能を マイクロサービス化 マイクロサービス化の範囲を 段階的に拡大 現在 モノリス型も 機能として 存在 次期会員基盤構築プロジェクト:段階的なマイクロサービス化 ・フェーズ1:現在の会員基盤をAWSへ移行 ・フェーズ2:機能単位で段階的にマイクロサービス化を実施 ・フェーズ3:全機能がマイクロサービス化され、各種要件を迅速且つ柔軟に取込める状態を実現 次期会員基盤を 利用する各サービスシステム 2025年度 2026年度~ 2027年度~(予定)
  8. Copyright © NIFTY Corporation All Rights Reserved. 12 会員管理システムの構成と移⾏後の構成 主な変更点

    • FJcloud-VからAWSに移行 ◦ すべて仮想サーバの環境からの移行 • API/バッチの仕様は変えない ◦ クライアント側の切り替えコストは 極力減らす • アプリケーションには ECS Fargateを採用 • DBはRDSを採用して フルマネージドに • IaCはChefからTerraformに変更
  9. Copyright © NIFTY Corporation All Rights Reserved. 13 エンジニア組織全体と今回のSREのEmbedded ストリームアラインド

    ISP Web CS イネイブリング QA セキュリティ SRE コンプリケイテッド‧ サブシステム ISPネットワーク プラットフォーム 会員管理 クラウド 戦略 課⾦‧請求 社内情報 データ基盤 ネットワーク‧ サーバ Embedded (常駐) 期間:2025/04 ~ 2026/01 人数:チームメンバー4名+SRE1名    (社外リソースはゼロ) 手法:スクラムイベントだけ    借りたウォーターフォール 部署をまたいでのEmbedded
  10. Copyright © NIFTY Corporation All Rights Reserved. 16 • 社内SREチームから

    「Embedded SRE参画の大規模案件のモデル ケースにしたい」 と打診された。 • 正直SREを受け入れることがどういうことかよくわ かっていなかったが 「人手足りないからウェルカム」 くらいのつもりで 受け入れた なぜEmbedded SREを受け⼊れることになったか
  11. Copyright © NIFTY Corporation All Rights Reserved. 17 参画にあたり「やること」と「やらないこと」の境界線を明確化した やるべきこと(SRE

    Scope) やらないこと(App Scope)  AWSアーキテクチャの選定‧設計 アプリケーションのコード修正‧機能追加  インフラ構築およびIaCの整備 アプリ単体/結合テストの動作確認  スクラムイベントへの参画 ビジネス部⾨や利⽤部⾨との仕様調整‧交渉  オブザーバビリティ設計、モニタリング整備、  SLI/SLOの決定、CI/CD構築や  キャパシティプランニング Embedded SREの役割定義
  12. Copyright © NIFTY Corporation All Rights Reserved. 19 プロジェクトのフェーズごとの状況 プロダクション

    環境並行稼働 ~リリース リハーサル兼 ステージング環境 デプロイ ~社内連携試験 実装~テスト フェーズ 設計フェーズ 2025/04 2026/01 2025/07 2025/11
  13. Copyright © NIFTY Corporation All Rights Reserved. 20 初期:設計フェーズ システム移行にあたり主に全体のアーキテクチャを考えるフェーズ

    プロジェクトフェーズごとの状況 SREの知見を借りながら 設計をしていった 一緒にタスクに 取り組めていた 4月 5月 6月 7月 8月 アーキ設計 ローカル環境整備 全員で同じタスクに 取り組む状態
  14. Copyright © NIFTY Corporation All Rights Reserved. 21 中期:実装〜テストフェーズ 膨大な量のAPI、バッチのテストを実施するフェーズ。

    ものによってはテストコードの作成から実施。 プロジェクトフェーズごとの状況 アプリケーションチームがテスト に忙殺されはじめて、 SREにやってもらうタスクの 管理が段々とできなくなってき た 6月 7月 8月 9月 10月 コード検証とテストコード整備 デプロイ設計 通信要件まとめ アプリケーションチームの 8割くらいの工数がここに SREのメインタスク アプリケーションチームは こっちはやや片手間
  15. Copyright © NIFTY Corporation All Rights Reserved. 22 後期:ステージングデプロイ〜社内連携テストフェーズ ステージング環境デプロイ後、リリースに向けて社内調整や各クライアントシステムが切り替え

    対応をしてくれたかの調査や発覚したバグ修正などを実施するフェーズ プロジェクトフェーズごとの状況 リリースが近づくにつれ、アプ リケーションチームと SREチームがやることが完全 に分断してきた 10月 11月 12月 バグ修正 社内調整 並行稼働チェック 当日メンテ手順検証 モニタリング整備 サブシステムのIaC整備 SREはこちらにノータッチ アプリケーションチームが こっちに時間をさけず SREが自発的にやってくれる
  16. Copyright © NIFTY Corporation All Rights Reserved. 23 直⾯した課題 並列進⾏によるタスクの分断

    スケジュールやタスクの性質の都合上並⾏していくつかの ストーリーを進めていたことでアプリケーションチームと SREのタスクの乖離が発⽣し、分断が少しずつ⼤きくなっ てくる。それによってSREのやっているタスクや成果物の 詳細をアプリケーションチームが追えなくなってくる。 SREが出したPRの蓄積の常態化 IaCのPRなどSREがやったタスクがボードのIn Reviewに 溜まる。技術スタックが違うことや他タスクで時間が取 れず、レビュー待ち多数が常態化していってしまう。 Embedded SRE参画の決め事による影響と分断の発⽣ 23
  17. Copyright © NIFTY Corporation All Rights Reserved. 対⾯レビューの頻度を増やす 隔週だったレビュー時間を 毎週に変更

    常に10個前後溜まっていた PRが2〜3個程度になった。 デモ形式レビューの承認 コードを読むだけでなく、実 演を⾒てその場で判断。 レビューの⼼理的ハードルを 下げた。 プランニングの前倒し まだ先の時期にやる予定の ストーリーでもプランニング を⾏い、⾃発的にSREが動け る状況を作り出した。 課題解決のために取り⼊れた改善策 24 「SREがやっていることの詳細がかわからない」 「SREがやったタスクのレビューがたまっていく」 SREが「何をやればいいかわからない」という状態を解消した
  18. Copyright © NIFTY Corporation All Rights Reserved. 25 Embedded SREのこういう振る舞いが嬉しかった

     ドメイン領域への関与 「アプリケーション周り はやらない」と決めてい たが、アプリケーション やドメイン知識が必要な 部分にまで踏み込んで 関わってくれた。  的確なたくさんの指摘 設計やインフラやモニタ リング周りにおいて、 ⾃分たちだけだと気付け ない部分を的確に指摘し てくれた。  直接の対話‧質問 気になったことや疑問点 があれば、躊躇せずどん どん直接質問しに来てく れて、対話が進んだ。  仮説検証と新たな提案 事前に仮説検証を⾏った 上で、 「こういう取り組みを やっていいか」と前向き に提案してくれた。
  19. Copyright © NIFTY Corporation All Rights Reserved. Embedded SREがもしこうだったら嫌だった 

    作成するドキュメントの 粒度の不⼀致 ドキュメント粒度をアプリケーショ ンチームのレベルに合わせてくれな い。 ⚠ 理解できないとEmbedded終了後、 SREが残してくれたものが負債になる。  プロダクトへの無関⼼ SREとして関わっているプロダクト に興味を持たない。 ⚠ 当事者意識が⽋け、チームとの温度 差や場合によってはプロジェクト失敗要 因となりうる。  SRE内での完結による 情報共有不⾜ 複数⼈のSREがいる時にSRE間で解 決してしまい、アプリケーション チームが知らない状態を作る。 ⚠ アプリケーションチームへの共有や フィードバックがなく、知⾒が還元され ない。 26
  20. Copyright © NIFTY Corporation All Rights Reserved. 27 チームに残してくれたもの •

    CI/CDのパイプラインによるデプロイの⾼速化 ◦ 現在もそのパイプラインをベースに改良を続けている • terraform によるIaC ◦ IaCベースでインフラ管理を⾏うようになった • ダッシュボードを⾒ることの習慣化 ◦ ⽣ログではなくダッシュボードで⾒るようになった ◦ ⾜りない情報をダッシュボードに追加する習慣が出来た SREが残してくれものをベースにチームの開発が動くようになった。 Embedded SREがもたらした具体的な成果
  21. Copyright © NIFTY Corporation All Rights Reserved. 28 「やるべきだと思っているけれど、 リソース的に⾃分たちではできなかったこと」

    そこに全⼒で伴⾛してもらって、 形を残してもらえたことが最⼤の勝因。 安定稼働ができようになった。 Embedded SREへの感謝
  22. Copyright © NIFTY Corporation All Rights Reserved. 29 Embedded SREを受け⼊れる時にすべきこと

    • SREにやってもらうこと、もらわないことを明確に決める • SREの成果物をどうレビューしていくかのルールを決める • 別のチームの⼈が⼿伝いに来てくれた、ではなく⾃チーム のメンバーとして受け⼊れる まとめ ⽂化やコードなどを残してくれて、Embedded SREを受け⼊れてよかった!