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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

VPCの構成  

Slide 16

Slide 16 text

NATGatewayについて  

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

ポイントシステム刷新  

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

After AWS   After AWS  

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

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