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

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © NIFTY Corporation All Rights Reserved. 2 ⻄原俊輔 (Nishihara Shunsuke) ニフティ株式会社所属。2007年新卒⼊社。会員基盤系システムのバックエンドエンジニア。社内スペシャリスト制度「N1!」のIDアーキテクト現在は「次期会員基盤」プロジェクトの推進を担当。 SREについてはあまりに知⾒がない。趣味はスティールパンとトランペット。 @shun_nishi ⾃⼰紹介 N1!IDアーキテクト

Slide 3

Slide 3 text

1986年の創業以来、⽇本のネットワーク⽂化を牽引。現在はノジマチームの⼀員として、 ISP事業を起点として、幅広いサービスを展開しています。私たちの使命は、130万⼈の⽇常を⽀える巨⼤な基盤を⾃ら「モダン化・内製化」し、技術の⼒でお客様に「いいこと」を届け続けること。35年以上の歴史を持つニフティだからこそ、社会的インパクトの⼤きい技術的挑戦が可能です。「ニフティとなにかいいこと、」をテクノロジーで体現し、お客様に最も近いISPへ。沿⾰ 130万⼈の会員基盤を⽀える、国内有数のインフラ。その安定した⼟台を、エンジニアの⼒で次世代へと進化させるノジマチームに参画 2017年 WEBサービス事業の⼀部であるマーケットプレイスサービスを承継した「ニフティライフスタイル株式会社」が事業を開始 2018年ポイントサービス「ニフティポイントクラブ」・会員向けアプリ「マイニフティ」提供開始 2021年「@nifty光 10ギガ」提供開始 2023年品川オフィスへ移転しノジマチームのシナジー強化 2026年 3

Slide 4

Slide 4 text

1 2 3 「つなぐ」の先にある、新しい当たり前を創る。⾼速で安定したインターネット接続を提供し、快適なデジタルライフの基盤を⽀えます。ニフティの事業と組織⽂化 ISP 通信からWebサービスまで、⼈々の⽣活を総合的に⽀える事業展開オプション Web お客様が安全・安⼼して利⽤できるよう、セキュリティやサポート体制を万全に整えています。情報収集から⼦供向けの安全な遊び場まで、多様なニーズに応えるコンテンツを提供しています。 4

Slide 5

Slide 5 text

事業の根幹を⾃らの⼿で創り上げる。妥協なき「内製化」へのこだわり私たちは、スピード感を持った事業展開と⾼い品質を両⽴させるため、システムの開発・運⽤を外部に依存しない「内製化」を強く推進しています。例えば、会員基盤やカスタマーセンタ−向けサポートツールの開発においても、要件定義の段階からエンジニアが深く介⼊し、⾃分たちの⼿で最適なアーキテクチャを選定・構築しています。ビジネスサイドとの距離も近く、ユーザーの反応をダイレクトに感じながらプロダクトを成⻑させていくことができる環境です。ニフティの事業と組織⽂化企画からインフラ構築まで。⾃社エンジニアで完結するモノづくり⽂化 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

ニフティグループは、お客様、株主、社員、パートナー企業、地域社会等の夢をかなえるため、常にお客様起点で⾏動し、チャレンジャーとしてサービスを開拓し、社会に役⽴つ企業として、新しい価値の創造に取り組み続けます。

Slide 8

Slide 8 text

Copyright © NIFTY Corporation All Rights Reserved. 8 ● 限られた期間の⼤規模移⾏プロジェクトの中でもIaCやモニタリングを導⼊することができた Embedded SREを受け⼊れてよかった！ ● プロジェクト内のどの範囲をSREに担ってもらうかを決めることが⼤事 ● SREが作ったリソースを負債にしないためにはプロジェクト期間中の定期的な対⾯レビューと対話が不可⽋ TL;DR

Slide 9

Slide 9 text

会員基盤システムの概要と移⾏プロジェクトの全容 9

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Copyright © NIFTY Corporation All Rights Reserved. 12 会員管理システムの構成と移⾏後の構成主な変更点 ● FJcloud-VからAWSに移行 ○ すべて仮想サーバの環境からの移行 ● API/バッチの仕様は変えない ○ クライアント側の切り替えコストは極力減らす ● アプリケーションには ECS Fargateを採用 ● DBはRDSを採用してフルマネージドに ● IaCはChefからTerraformに変更

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © NIFTY Corporation All Rights Reserved. 17 参画にあたり「やること」と「やらないこと」の境界線を明確化したやるべきこと（SRE Scope）やらないこと（App Scope） AWSアーキテクチャの選定‧設計アプリケーションのコード修正‧機能追加インフラ構築およびIaCの整備アプリ単体/結合テストの動作確認スクラムイベントへの参画ビジネス部⾨や利⽤部⾨との仕様調整‧交渉オブザーバビリティ設計、モニタリング整備、 SLI/SLOの決定、CI/CD構築やキャパシティプランニング Embedded SREの役割定義

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Copyright © NIFTY Corporation All Rights Reserved. 21 中期：実装〜テストフェーズ膨大な量のAPI、バッチのテストを実施するフェーズ。ものによってはテストコードの作成から実施。プロジェクトフェーズごとの状況アプリケーションチームがテストに忙殺されはじめて、 SREにやってもらうタスクの管理が段々とできなくなってきた 6月 7月 8月 9月 10月コード検証とテストコード整備デプロイ設計通信要件まとめアプリケーションチームの 8割くらいの工数がここに SREのメインタスクアプリケーションチームはこっちはやや片手間

Slide 22

Slide 22 text

Copyright © NIFTY Corporation All Rights Reserved. 22 後期：ステージングデプロイ〜社内連携テストフェーズステージング環境デプロイ後、リリースに向けて社内調整や各クライアントシステムが切り替え対応をしてくれたかの調査や発覚したバグ修正などを実施するフェーズプロジェクトフェーズごとの状況リリースが近づくにつれ、アプリケーションチームと SREチームがやることが完全に分断してきた 10月 11月 12月バグ修正社内調整並行稼働チェック当日メンテ手順検証モニタリング整備サブシステムのIaC整備 SREはこちらにノータッチアプリケーションチームがこっちに時間をさけず SREが自発的にやってくれる

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Copyright © NIFTY Corporation All Rights Reserved. 29 Embedded SREを受け⼊れる時にすべきこと ● SREにやってもらうこと、もらわないことを明確に決める ● SREの成果物をどうレビューしていくかのルールを決める ● 別のチームの⼈が⼿伝いに来てくれた、ではなく⾃チームのメンバーとして受け⼊れるまとめ⽂化やコードなどを残してくれて、Embedded SREを受け⼊れてよかった！