コープさっぽろでのAWS利活用〜AWS All-inに向けての取り組みのご紹介〜 / What we have done for AWS All-in

コープさっぽろでのAWS利活用   〜AWS All-in に向けての取り組みのご紹介〜   2023/7/25  生活協同組合コープさっぽろ  山﨑奈緒美 

AWS SAMURAI 2015   JAWS-UGアーキテクチャ専門支部   JAWS-UG情シス支部   生活協同組合コープさっぽろ  
デジタル推進本部システム企画部   インフラチーム  山﨑奈緒美ご挨拶と自己紹介大阪出身。  就職で上京し、ソフトハウスでインフラエンジニア  地図情報システム開発会社でひとり情シス  旅行会社の情シス部門でクラウド担当  2020年9月に東京から札幌へ移住し10月よりコープさっぽろへJOIN。  AWSのことならなんでも担当。  @nao_spon  I ♡  Route53   IAM  Organizations   夏はロードバイク、冬はスノボしてます。仲間募集中！ 

生活協同組合コープさっぽろとAWS  

生活協同組合コープさっぽろについて   設立年月日  1965年7月18日  組合員数  181万人（北海道総人口528万人の約34％）   出資金額  776億円  総事業高 
2,807億円  職員数  15,235名（契約職員・パートアルバイト含む）   店舗数  107店舗  移動販売車  94台（133市町村）  宅配物流センター  37センター、11デポ、車両1,100台   配食工場  6工場（札幌、函館、苫小牧、旭川、釧路、帯広）   生産工場  7工場  ※2020年3月現在 

北海道で生きることを誇りと喜びにする   3つのつなぐ   福祉活動文化教室組合員活動葬祭事業旅行事業物流事業
店舗事業移動販売宅配事業配食・給食食育食品製造共済事業エネルギー子育て支援環境活動リサイクルフードバンク育英奨学金と  人  人  をつなぐ  と  人  食  をつなぐ  と  人  未来  をつなぐ 

なぜコープさっぽろは   AWS All-inを目指すのか   コープさっぽろとAWS  

現在のAWS利用状況   総AWSアカウント数 334 オンプレ移行用AWSアカウント 147 新規システム用AWSアカウント 122 インフラ共通基盤用AWSアカウント 55
その他用AWSアカウント 10

長年の蓄積で負債の宝庫  • 古いOS  • 複雑なネットワーク  • 縦割りで乱立する基盤  • 高額なデータセンター代  •
etc...  コープさっぽろのシステムの今まで  

そうだ、AWSにしよう。   全部AWSに持ってったらええやんけ！ CIO 長谷川秀樹

どのように利用するか   AWS利用設計  

AWS利用のグランドデザイン   最初から複数アカウントを運用する前提で全体を設計  • アカウントの分離  ◦ AWS Organizationsを使用して統制  • マネジメントコンソールへのログイン方法 
◦ IAM Identity CenterとGoogleWorkspaceをSSO連携  • ネットワーク設計  ◦ 想定アカウント数からアドレスレンジを確保  • AWS利用ガイドラインの作成 

AWSアカウントの分離   • システム単位で分離  ◦ 同じAWSアカウントに他システムを相乗りさせない  • 環境単位で分離  ◦ 開発・検証・本番でアカウントを分ける 
◦ オンプレ環境に開発と本番しかない場合は2環境  ◦ 開発ベンダー側でAWSに開発環境がある場合は本番のみ  • AWSアカウント命名規則  ◦ 環境名-事業ドメイン-システム名  dev-deli-xxxx, prd-store-xxxx等 

マネジメントコンソールへのログイン方法   • IAM Identity Centerの利用  ◦ GoogleWorkspaceとSSO連携  • Permission
setsによるアカウント操作権限の分離  ◦ Admin, Builders, Operatorsの3つにグループを分ける  ◦ Adminはインフラチーム  ◦ Buildersは開発者  ◦ Operatorsは運用担当者  ▪ Read権限+EC2の起動・停止・再起動  ▪ みんなが慣れてきたら操作可能な権限を増やす 

ネットワーク設計   • 最低利用VPC数を割り出す  ◦ 180システム×3環境=540  ◦ /11で1024個のVPCを作れる  • AWSアカウント間のネットワーク 
◦ AWS Transit Gatewayを利用  • AWSとオンプレ間のネットワーク  ◦ AWS Direct Connectを利用  ◦ Active×Active構成 

VPCの構成  

NATGatewayについて  

AWS利用ガイドラインの作成   • AWSアカウント発行申請方法  • インフラチームと他チームとの役割分担を明記  ◦ VPCやDNS等のネットワーク関連はインフラTが作成  • リソースの命名規則 
• BuildersへのIAM User, Role作成権限抑制に関する注意事項  ◦ Permissions boundaryで制限  • セキュリティに関連する遵守事項  • サポート問い合わせ方法  • アーキテクチャレビューの実施 

AWSアーキテクチャレビュー   • インフラチームがレビュワー  • 内製開発分だけではなく外注で開発する場合も実施  • 構成がAWSのベストプラクティスになっているか  • リソースのサイズが過剰or過小すぎないか 
• 共通で利用するために用意しているものを  個別に作ろうとしていないか   

移行対象を見極める   AWS移行  

負荷の軽そうなものから？何から移行し始めるか   中身のわかるものから？壊れても大丈夫なものから？お金のかからないものから？
重要度の低いものから？

負荷の軽そうなものから？中身のわかるものから？壊れても大丈夫なものから？お金のかからないものから？重要度の低いものから？
どうせ中身なんか完璧に把握でけへんのやから、早う全部コピーせんかい！何から始めるか   CIO 長谷川秀樹

Lift & Shift ではなく Lift to Shift   1つ1つの中身を把握し、作り変えるのは時間がかかる •
まずはLift（そのままコピーして持っていく：V2V/P2V）  すべてAWSへLiftしたらクラウドネイティブな  構成へShift • FaaS/SaaSの活用 • そもそも作らない選択も

システム/サーバーのリスト化 • OSやミドルウェアなど条件を整理  ◦ 古いOSの把握  ◦ データベース  ▪ 腹持ちしているか  ▪
ライセンスは適切か  ◦ ハードウェアやアプリケーションの保守期限  ▪ 移行の優先順位決定に必要  移行対象を把握する  

移行対象を見極める   • 走りながら移行対象を変更していく  ◦ 利用終了できるシステムがあるのでは？  ◦ 他システムと統合できるシステムがあるのでは？  ◦ SaaSに置き換えられるシステムがあるのでは？ 
  事業部とのコミュニケーションも重要  

移行対象を見極める   • AWS環境での構築対象となるのは赤字のリホストとリビルド  • リビルドについてはAWS移行と並行して各チームでの対応を開始  • これ以外にも潜んでいるシステムがある  方式  総数 
対象  リホスト（AWS）  118  オンプレミスからAWSにリフトするシステム   リビルド  41  オンプレ環境を再構築や他システムへ統合するシステム   DC外  31  元々AWS環境やDC以外で稼働するシステム   廃止  39  利用終了や業務調整により廃止とするもの   合計  229  コープさっぽろシステム合計  

システムのSaaSへの置き換え   • 承認ワークフロー → Kickflow  • 小口経費・交通費精算 → マネーフォワード
クラウド経費  • 人事DB/給与明細 → SmartHR  • レシピサイト → note  • SlackとZapierとGoogleDriveの活用  ◦ システム部への業務依頼WEBシステムを置き換え   

どうやって移行するか   AWS移行  

移行ツールの選定   • Server Migration Service • AWS Application Migration
Service AWSへV2V/P2Vする選択肢  • ダウンタイムが少ない • Direct Connect経由の移行が可能 • 帯域制限が可能 • 直接VPCにコピー可能  → 以下の理由からAWS Application Migration Service を選定

• AWS Application Discovery Service  通信状況をキャプチャしAWSに送信  通信調査ツール • 長年の運用で、どんな通信が行われているか把握できない環境がある 
移行ツールの選定  

Active Directoryの移行   • AWS Directory Service (AWS Managed Microsoft
AD)  ◦ マネージドサービスのAD ◦ OSレイヤーを気にせず運用できる   サーバーのみ使用で運用

ひたすらにコピー   単純コピーは簡単とはいえ障害もある • Oracle/SQLServerのライセンス • クラスタ • 古すぎるOS
◦ AWS Application Migration Serviceが  インストールできない ◦ 諦めて載せ替えも全コピー完了へ向けて邁進中！

現在のAWS移行の状況   AWS移行  

脱オンプレ全体状況   • AWS環境での構築対象となるのは赤字のリホストとリビルド  • リビルドについてはAWS移行と並行して各チームでの対応を開始  • これ以外にも潜んでいるシステムがある  方式  総数 
完了  対象  リホスト（AWS）  118  80  オンプレミスからAWSにリフトするシステム   リビルド  41  13  オンプレ環境を再構築や他システムへ統合するシステム   DC外  31  29  元々AWS環境やIDC以外で稼働するシステム   廃止  39  27  利用終了や業務調整により廃止とするもの   合計  229  149  コープさっぽろシステム合計  

オンプレからの移行状況   オンプレ移行対象システム数  118  移行仕掛中システム数  38  本番移行済みシステム数  80  オンプレ移行対象サーバー数  797 
AWS移行済みサーバー数  267  ※EC2 228台＋RDS 39台  

オンプレからの移行状況   オンプレ移行対象システム数  118  移行仕掛中システム数  38  本番移行済みシステム数  80  オンプレ移行対象サーバー数  797 
AWS移行済みサーバー数  267  ※EC2 228台＋RDS 39台   移行完了まで残38システム！  

コープさっぽろと内製開発   コープさっぽろと内製開発  

コープさっぽろのシステム部の今まで   • 90％のシステムが開発ベンダーへ外注  • 他の事業部からは何をしているか良く分からない部署  • 開発ベンダーからの見積に対する精査ができない  • システム部から現場部門へ提案することがあまりなかった 
• 現場部門からシステム部へ異動してきたメンバーが多い  • 業務システムのスペシャリスト≠IT技術のスペシャリスト 

内製開発について   • エンジニア採用を実施  ◦ PM、開発者、インフラエンジニア  • 内製エンジニア+外部委託エンジニアで開発  • 全てを内製開発するわけではない 
 

内製開発について   • 現場研修を通じて業務を理解し、事業が自分ごとになる  • 「中の人」として現場業務の改善提案と実装を行う  • 開発を外注する場合でも見積が妥当かを判断できる  • システム部の取り組みを他部門へ発信する文化が生まれる 
• 他部門からシステム部への相談が増えた 

システム部の取り組みの発信   https://dx.sapporo.coop/  

現場に溶ける   現場・現物・現実を知る  

現場研修について   • 店舗研修3日間  ◦ 店長業務、畜産部門、農産部門、惣菜部門、食品部門  • 宅配研修1日間  • 食品工場研修1日間 
• 移動販売車研修1日間  • 物流センター研修1日間 

現場支援  • イベント運営  ◦ 海のクリーンアップ大作戦  ◦ 食べる大切フェスティバル  • 年末商戦店舗支援  ◦
クリスマス用オードブル調理  ◦ 大晦日用お寿司製造  ◦ みかんチェック  • 新店開店時支援  • 宅配雪害時応援対応 

現場に行くことのメリット   • 現場での業務を知ることができる  • 改善点を見つけられる（かもしれない）  • 現場の人たちと直接話ができる  • 現場の人たちと仲良くなれる 
• バーターでPOC協力依頼ができる 

内製開発とAWS   内製開発とAWS  

46 店舗アクティブ利用者 105万人   宅配アクティブ利用者   49万人   トドックアプリ  

ポイントシステム刷新   ポイント利用促進アプリでポイントステージを確認簡単にポイント利用可能

ポイントシステム刷新  

内製開発したもの   • 宅配注文スマホアプリ  • 宅配注文WEBサイト  • 宅配注文API基盤  • 宅配申込み 
• 電子組合員証  • ポイントシステム  • 給食システム  • 資源回収システム  • 共通認証基盤 

サービス選定時に検討する順番   • Lambdaでできるか • コンテナでできるか • それでもダメならEC2   コンピュート 
• Auroraでできるか  • RDSでできるか  • それでもダメならEC2  データベース 

サービス選定時に検討する順番   スケールアウトしやすい構成になっているか • なるべくCloud Nativeなマネージドサービスを使う • 難しい場合はなるべく疎結合にする • ワークロードでリソース分離する

リソース管理   Infrastructure as Code • 環境設定記述書の代わりにできる  • 同じ or
似たような構成の場合に構築スピードが速くなる  • チームメンバーの特性によって宣言型、手続型を選べる  ◦ インフラチームの場合は宣言型のCloudFormation  ◦ アプリ開発者は手続型のCDK  • コードに "Why" を残せる  • GitHub ActionsやCircleCIと連携して自動デプロイができる 

Observability - 可観測性   Application Performance Monitoring (APM) • NewRelicを利用 
• バックエンドのAPIやDBクエリのレスポンス状況がわかる  • インフラリソース、アプリケーションログと一緒に横串で見れる  • ボトルネック調査がしやすい 

After AWS   After AWS  

After AWS   • データセンターへ駆けつける回数が格段に減った  • システム単位でかかる費用がわかりやすくなった  • サーバーの再起動が怖くなくなった  •
インフラのスペック問題が無くなった代わりにアプリ自体の  性能問題が浮き彫りになるようになった  • インフラ構成のリファクタリングがしやすくなった  • POCをしやすくなった 

ありがとうございました   https://www.wantedly.com/companies/company_7505384  

コープさっぽろでのAWS利活用〜AWS All-inに向けての取り組みのご紹介〜 / What...

コープさっぽろでのAWS利活用〜AWS All-inに向けての取り組みのご紹介〜 / What we have done for AWS All-in

More Decks by Naomi Yamasaki

Other Decks in Technology

Featured

Transcript