『初心者でもできた！
CloudEndure を利用した
PLMシステム群のAWS の移行』
里山元章 日立Astemo株式会社 情報システム統括本部 C U S - 3 8このセッションの対象者
これから アマゾン ウェブ サービス (AWS) を利用しようと
思っている人への事例紹介です
✔
自社システムをAWSへ移行したい
✔ AWSへの移行について興味がある方
✔ 技術的にもAWS初心者
初心者発表者の紹介
氏名：里山元章（サトヤマ モトアキ） 経歴 1987年 日立製作所 システム開発研究所入社、OS、ネットワーク、GUI、 組込ソフトウェアなどの研究開発に従事 2004年 同社ソフトウェア事業部でストレージ制御ソフトの開発に従事 2009年 同社RAIDシステム事業部にてストレージシステムの開発に従事 2014年 同社ITサービス本部にて日立グループのITインフラストラクチャの近代化に従事 2019年 日立オートモティブシステムズ（現：日立Astemo） にてITシステムの近代化・グローバル標準化を推進中会社概要
日立Astemo株式会社
自動車部分品および輸送用ならびに産業用機械器具・ システムの開発、製造、販売及びサービス
プレジデント＆CEO ブリス・コッホ (Brice Koch)
茨城県ひたちなか市高場2520番地 商 号 事業内容 代 表 者 設 立 本社所在地 2021年1月1日 東京都千代田区大手町二丁目2番1号 新大手町ビル 本店所在地 資本金 515億円
ごあいさつ
2021年1月、日立Astemoは、モビリティソリューションの提供を通じ、持続可能な社会に大きく貢 献し、世界をリードする企業として、日立オートモティブシステムズ、ケーヒン、ショーワ、日信工業の 統合会社として誕生しました。
Astemoに込めた思い
私たちは、世界をリードする先進的なモビリティソリューションの提供を 通じて、持続可能な社会と人々の豊かな生活の実現に貢献します
本日の発表内容
『初心者でもできた！CloudEndure を利用したPLMシステム群のAWSの移行』
項 目 何を PLM (製品ライフサイクル管理) 関連の26システム いつ 2020年4月~8月 だれが 日立Astemo ITチーム どのように CloudEndure Migrationを利用 なにをした オンプレミス環境からAWSへ移行まずはITインフラ近代化の方針を立てる
業務要件に合った最適なインフラへの近代化と標準化を進める
クラウド オンプレ(エッジ) ハイパーコンバージドインフラ ストラクチャで標準化 ワークフローなど広く従業員が使い ユーザエクスペリエンスが重要なアプリ IoT系などリアルタイム性が必要顧客(OEM先)からの指定・認定 生産・製造・設計系やERPなど構 成の柔軟性やオンプレミス(エッジ) とのインターフェースがあるアプリ IaaS/PaaSで標準化 SaaSとそのLow code Platform
移行対象システムを選定
移行対象：製品ライフサイクル管理システム
設計手配システム、図面管理システムなど設計を支援する複数から構成されるシステムで 一般的にPLM(製品ライフサイクル管理)システムと呼ばれる。移行対象の選定理由
✔
保守運用サービス付のオンプレミスのハードウェア・ソフトウェア ✔ 2020年8月でハードウェアの保守期間が終了 ✔ 契約を更新せず、クラウドへの移行を決断開発方針（内作・外作）を決める
これまでのIT部門の仕事：ユーザの要望をベンダーへ伝えて作業してもらう
✓ ITエンジニアなのに、事務処理（発注、検収、、）が多い ✓ 実はベンダーが言っていることもよく分からないけど、いまさら新しいことを勉強するのはどうも ✓ ITへの要望は多いけど人も金も無いと感じていた自分たちでITインフラの近代化を行う
✓ プラットフォームの近代化と人財の近代化を行う ✓ 新しい技術を学ぶ楽しみを思い出してもらう（高齢化したITチームの活力向上）✓ 最新のプラットフォームのCoE (Center of Excellence) として事業貢献できるチームに
AWS PS(Professional Services)を活用
移行をSIベンダーに依頼する ・ 確実に移行ができる ・ 期限が設定できる ・ 費用がかかる ・ Astemo側に技術スキルが残らない コロナ禍のため、すべて リモートにて行う • 内作化を前提とし、正しい知識と経験を得るため、コーチとしてAWS PSを活用 • 自分たちでやってみて困ったときに相談する（技術を得るための活用なので、丸投げしない） クライアントとベンダでなく、 師匠と弟子の関係を構築AWSへの移行全体像
ステップ0 知識、技術を 理解する • AWSのトレーニング ステップ１ 情報取集と分析 • 現システム環境から移行 ステップ２ 基本システム 構築 • 収集・整理した情報から ステップ３ データ移行 と周辺機能構築 • 実データを移行 • 監視機能など事前に無償トレーニングで基礎知識をつける
# 日付 内容 人数 1 2019/5/30 スケーラブルハンズオン 50名 2 2019/9/11 AWS基礎勉強会（ユーザ部門の参加） 120名 3 2020/01/23 AWS 移行に向けての今後の進め方 3名 4 2020/03/09 AWSコアサービスとDB移行ハンズオン実施 (インフラ部門向け) 10名 5 2020/04/09 AWSコアサービスとDB移行ハンズオン実施 (アプリ部門向け) 30名 6 2020/04/22 マルチアカウント管理におけるコスト管理 (AWS Organization) 3名 7 2020/12/09 AWSとの外部接続セキュリティ 勉強会 8名 8 2021/01/20 マルチアカウント管理におけるAWS Control TowerとOrganization 12名延べ236名 • IT部門だけでなくユーザ部門も巻き込んでトレーニングに参加してもらう • ハンズオン・トレーニングを受けてアカウントを作る⇒在宅でも自習できる状態を作る • コロナ対策もあり途中からすべてオンライントレーニング ☚4月中旬 プロジェクト開始 ☚8月中旬 移行完了
ステップ０：トレーニング
# 日付 テーマ 人数 1 2020/4/23 AWS移行計画の立て方 20名 2 2020/5/14 CloudEndureによるマイグレーション手法 20名 3 2020/5/21 Amazon RDS設計のポイント 20名 4 2020/6/4 2020/6/11 セキュリティワークショップ 7名 5 2020/7/2 コスト管理,タグ運用 7名 6 2020/7/9 Amazon EC2接続手法整理 7名 7 2020/7/16 バックアップ運用 7名 8 2020/7/30 インベントリ管理、パッチ管理 7名 • 選抜して有償トレーニングを受講しさらに知識を強化 • 専任のチームは4名程度（＋ピーク時支援を想定したインフラ要員とインフラ管掌管理職） ☚4月 プロジェクト開始ステップ１：情報収集と分析
ステップ１ 情報収集 まずはとにかく台帳を作る ✔ ツールを使って「世界地図」を描く ① ハード・アプリの一覧 ② 通信プロトコルの解析調査 ③ 開発/本番/検証などのラベル付け ✔ 収集データを元に作戦を立てる ① 移行単位を決める ② 優先順位を決める ③ 移行方針を決める ④ 移行方法を決める ⑤ 想定のコストを見積もる サーバ一覧 アプリ名、ベンダ名、言語、DB種別、 OS、IPアドレス、ホスト名など 通信一覧 プロトコル種別、ポート番号など ベンダーに 任せていた システム • AWSソリューションアーキテクトに調査観点をレビューしてもらう • 各種ツールを使って現状把握移行対象のオンプレミスサーバ
OS 本番 開発 • 物理サーバ：14台、Oracle DBアプライアンス：4台、ストレージ約8TB • ホストOSは96本(本番67本、開発29本) • OSバージョンは Windows 2012R2 std以降のみ 開発, 29移行アプリケーションの内訳
商用パッケージ, 23% VB+.NET, 50% その他, 27% アプリケーション (26本) Oracle, 84% SQL, 8% その他, 8% 移行元データベース • 移行するアプリケーションは26システム• 商用パッケージが23％、Microsoft Visual Basic (.NET Framework) による自製アプリが 50%、その他言語の自製アプリ27%
データベースの移行先
Amazon EC2(Oracle), 4% Amazon EC2(SQL), 7%
Amazon EC2(その他), 8%
移行後のデータベース
• 81%を Amazon RDS for Oracleへリプラットフォーム
情報収集ステップで分かった課題と対策
•
パッケージソフトのクラウド利用制限(ライセンス問題や動作保証)
✓ すべてのパッケージソフトベンダとライセンスや保守契約の見直しを実施 ✓ クラウドで利用できないアプリは制限・廃止する方針•
日立イントラネットとインターネット間の通信制限(dblinkなど制限)
✓ 日立の専門部隊に支援頂き、セキュリティ対策を実施の上で接続•
顧客から認定を受けたハードしか利用できない業務
✓ データセンターから利用単価が安い自社サーバルームへ移設（クラウド利用は断念）ステップ２：コア部分の設計と構築
ステップ2情報収集したデータを分析して設計し構築する
サーバ アプリ DB ネットワーク/セキュリティ OS CPU メモリ ストレージ 開発/本番 稼働状況調査と 簡易サイジング サイジング ライセンス サービス 使われ方 必要か？ 利用状況や ライセンスの調査 ライセンス 種類 性能 容量 バージョン、容量、 DBエンジンの選択 セキュリティポリシー 帯域 ELB ネットワーク/セキュリティ など要件確認管理者権限の管理 (AWS IAM)
1. AWSアカウント管理者 (ルートユーザ) ルート権限、日常運用では【原則使用しない】ものとする パスワードは最強な強固を維持する。IAM編集権限を待つ。 2. 管理者グループ (インフラ運用管理者) すべてのインフラリソースの変更、操作権限を持つ。 ただし、VPCの変更はできない。 3. 開発グループ (アプリ開発者) 開発リソースの新規作成、削除、編集、操作権限を持つ。 4. 運用グループ (アプリ運用者) リソースの編集、操作権限を持つ。 インスタンスの起動、停止はできるが、インスタンスの作成、削除はできない。 5. 外部ベンダーグループ 作業委託しているベンダーごとにグループ作成。有効期限を設ける。 権限は4.開発グループと同じ。• AWS Identity and Access Management (IAM)を活用
• シンプルに5グループに分け、責任と用途に応じ使い分けた運用設計 AWS インスタンス 権限の強さ 強 弱 インスタンスの起動・停止のみ すべての権限を有す
監視・運用 (Amazon CloudWatch)
監視・運用 【運用体制】 ✓ ツールによる24時間365日 常時監視 ✓ 障害発生時における情報提供やサポート ✓ AWS特有のオペレート、技術支援 【主要機能】 ✓ ツール(CloudWatch等)を用いたAWS内 リソース・モニタリングの一元化と標準化 ✓ 監視画面提供と閾値設定 (障害システム、 箇所、内容などを迅速に表示・連絡) ✓ 発報システムと他ツール連携 (メール以外にも Teamsや他SNSも活用) 障害情報 対応サポート 情報収集 障害 ナレッジ 障害 詳細情報 拡張コンサルアプリ
チーム
予防検知報告 監 視 対 象インフラ
社内展開支援 障害分析 影響範囲報告 監視 Amazon CloudWatchAWS Systems Manager
運用
• Amazon CloudWatch と AWS Systems Managerの活用 • 簡単に使えるリソース監視と障害検知、調査のツール
データ移行の方法 (AWS CloudEndure)
CloudEndure ・ エージェント型の簡単な移行支援ツール ➢ 2019年6月から無償に ➢ 物理サーバからも移行できる ➢ 最も簡単に移行できる VM Import/Export AWS Server Migration Service AWS Database Migration Service CloudEndure MigrationAWS Server Migration Service
AWS Database Migration Service ・ 手軽にできるコマンド型移行 ➢ 既存の仮想マシンイメージをAWSで利用できるようにする ➢ 開発・検証機など一定時間停止が許容されるものに利用 ➢ 差分移行はできない ・ 仮想基盤と連携する移行ツール ➢ VMware vCenter / Hyper-Vと連携 ➢ 本番き含めて段階移行する場合に利用 ➢ 差分移行も可能 ・ DBだって移行できる！ ➢ 仮想・物理、他社クラウドからのDB移行 ➢ エージェント導入による常時同期によるダウンタイム低減 ➢ 異なるデータベースエンジンにも移行が可能 採用
Amazon Simple Storage Service
CloudEndure Migration
移行対象 サーバ群 移行の開始/停止 の制御が可能 エージェント • AWS上で無償で提供されるデータ移行ソリューション • 移行対象サーバに専用エージェント、AWS側にReplication Serverを配置 • 専用ポータルから複数サーバのオンライン同時移行を管理できるCloudEndure (CUTOVERMODE)
