Slide 1

Slide 1 text

DXを加速するAWS活用法 NCDC Onlineセミナー 2020年12月16日 NCDC株式会社

Slide 2

Slide 2 text

三浦 洋平 ITコンサルタント NCDCでは、 AWSアーキテクチャコンサル ティングを中心として様々なプロジェクト に従事。 AWSの大規模IoTプラットフォーム構築に加 え、JavaScript(React)を主としたフロントエ ンド開発、スマートフォンアプリ開発も経 験し、フロントからインフラまで幅広い領 域に対応できる技術力を持つ。

Slide 3

Slide 3 text

NCDCのご紹介

Slide 4

Slide 4 text

私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP(Minimum Viable Product)を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善

Slide 5

Slide 5 text

私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニ アによる技術移管まで、幅広くお客様をサポートします。 5 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング

Slide 6

Slide 6 text

Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 6 NCDCのサービス体系

Slide 7

Slide 7 text

本日の内容 l DXにおけるクラウドの役割 l DXとは何か l クラウドの特徴 l DXにおけるクラウドの役割 l クラウド活用のポイント l クラウド活用の3つのハードル l 不確実性への対応 l クラウド活用事例 l クラウドプラットフォームの選定 l まとめ 7

Slide 8

Slide 8 text

DXにおけるクラウドの役割

Slide 9

Slide 9 text

DXとは何か l DX= 先端技術を用いて、業務・サービスをデジタル化することで、 今までにない新しい価値の提供・業務効率化を行うこと l 先端技術: AI、IoT、クラウド、SPAなどの新しい技術、マイクロサー ビスやアジャイルなどの方法論 l 今までにない新しい価値:先端技術で実現される、今までできなかっ た新しい体験・機能 l 業務効率化:引き続きITシステムにおける関心事項 l 単なるIT化の延長ではなく、新しい技術で新しい価値を届けるこ とがDXの文脈では求められている 9

Slide 10

Slide 10 text

クラウドの特徴 l 高い拡張性 l 計算資源を柔軟に拡張可能 l 様々なサービスと連携 l 従量課金の課金体系 l 使った分だけ課金される l イニシャルコストがゼロに近い l 構築・維持の外部化 l インフラ構築の具体的作業を意識する必要がなく、アプリケーション 部分に注力できる l プログラムによる自動化が容易 10

Slide 11

Slide 11 text

DXにおけるクラウドの役割 l DXの最大のポイント:不確実性 l 新しい技術・新しい価値・変化の早い時代 l アジャイル的な手法が重視されるように l インフラ部分での変化への対応力を実現するのがクラウド l 業務効率化においてもクラウドは大きな威力を発揮 l 開発効率の向上:DevOps基盤の提供 l インフラコストの削減:主として運用コスト 11

Slide 12

Slide 12 text

ここまでのまとめ 12 ❌ クラウドを使うのがDX ⭕ 不確実性の⾼いDXという取り組みに 柔軟に対応できるようにクラウドを使う

Slide 13

Slide 13 text

クラウド活用のポイント

Slide 14

Slide 14 text

「EC2クラウド」からクラウドネイティブへ l 「EC2クラウド」 l AWS EC2やRDSをリモートサーバーとして利用 l 多くの企業で活用されているAWSの利用形態 l SIerを中心とした販売代理ベンダーが運用・維持 l クラウドネイティブ l クラウドプロバイダーが提供するサービスをフルに使用 l コンテナ、サーバレス、AI、IoT、CI/CD、ライブストリーミング、etc… l 無数にあるサービスを有機的に組み合わせ最適なアーキテクチャを構 築する必要がある 14

Slide 15

Slide 15 text

クラウド活用の3つのハードル 1. 適切な技術の選定 2. クラウド活用の人材確保 3. セキュリティを含めた社内制度 15

Slide 16

Slide 16 text

クラウド活用の3つのハードル 1. 適切な技術の選定 l EC2 + RDSでは不十分 l AWS東京リージョンには150以上のサービスが存在 l 必要なものを適切に選ぶ l 使ったことのないサービスの方が多い → 手を動かす必要がある l Webサービスにおける標準はある程度定まってきている l 実際には、様々な制約から三者三様なアーキテクチャになる l 社内ネットワーク・既存システムとの接続 l セキュリティやアプリケーションの制約 l 期間・人材・将来的な戦略との兼ね合い 16

Slide 17

Slide 17 text

クラウド活用の3つのハードル 2. クラウド活用の人材確保 l クラウド人材 ≒ DX人材と言っても過言ではない l クラウドエンジニアだけではダメ l DXは業務・アプリ・インフラすべての観点が必要 →DXは今までにない新しい価値を提供する取り組み l 全てに精通している必要はないが、全てに関心を持つ必要がある l 縦割りの役割分担ではうまくいかない l ユーザー(ビジネスサイド):開発やインフラへの理解が求められる l アプリ開発者:業務知識 + インフラの基礎知識 l インフラエンジニア:アプリ構成への理解、ビジネス側との非機能要件部 分に関する対話が必要 l アジャイルチームを組んでプロジェクトに当たる 17

Slide 18

Slide 18 text

クラウド活用の3つのハードル 3. セキュリティを含めた社内制度 l 社内の壁 1:セキュリティ l そもそもクラウドがダメ l 新しい仕組みは社内にルールがない → 安全側に倒して禁止 l 社内の壁 2:不確実性 l 試作しなければわからないことも多い → 確実な成果が見込めないとGoが出ない l 事前調査やPoCを十分に行わない、納期に余裕を持たない l 社内の壁 3:縦割り部署 l あのシステムは○○部、あそこのネットワークは××部、・・・ l アジリティ・柔軟性が下がる 18

Slide 19

Slide 19 text

どうするか 1. 最新技術へのキャッチアップ 2. アジャイルを中心としたチームビルディングと人材戦略 3. ある程度トップダウンで巻き込む 19

Slide 20

Slide 20 text

どうするか 1. 最新技術へのキャッチアップ l 社内に技術者がいるならそれに越したことはない l 各メンバーが自主的に情報収集する l 皆さんのことです l アプリ開発者、クラウドエンジニアと会話できるレベルでは理解しておく l 自社のシステム構成やインフラ構成の概要をしっかり説明できますか? l 外部リソースを活用する l NCDCのことです l 技術を持っている会社は多いが、適切に力を借りるのは難しい l 「自分たちも何をやりたいかわかっていない」ことがよくある (決して悪いことではなく、DXの特性として) l クラウド移行を試す 20

Slide 21

Slide 21 text

どうするか 2. アジャイルを中心としたチームビルディングと人材戦略 l 一人で全領域をカバーする必要はない、チームでカバーできればよい l アジャイルにおけるチームづくりが参考になる l 様々な役割を持つメンバーが上下関係なく意見する l お互いがお互いの領域に関心を持つ l 開発はベンダーさんにお任せ、ではうまくいかない l 柔軟に動いてくれるか協力会社を見極める l なんでもイエスと言ってくれるということではない l DXを推進できる人材を社内で育てる l 事業会社の場合、エンジニアが足りていないことが多い l エンジニアがいない場所にエンジニアは来ない 21

Slide 22

Slide 22 text

どうするか 3. ある程度トップダウンで巻き込む l 社内制度や権限については上位層が動いてくれないと厳しい l 自分たちの挑戦に価値があると経営層を納得させる説明ができるか? l 小さく始めて成果をつくる l 他社事例や外部の意見を持ち込んで説得する l 巻き込む範囲はなるべく広く、巻き込む人はなるべく少なく l 社内に広く協力してもらう l 意思決定の人数が増えると動きが鈍るので、決済者を巻き込む l セキュリティや不確実性に関しては論理武装を l GoogleやAmazonより高いセキュリティが必要ですか? 22

Slide 23

Slide 23 text

ここまでのまとめ 23 クラウド活⽤の3つのハードル 適切な 技術の選定 クラウド活⽤の ⼈材確保 セキュリティを 含めた社内制度 とるべき対策 最新技術への キャッチアップ アジャイル体制と ⼈材戦略 トップダウンで 巻き込む

Slide 24

Slide 24 text

不確実性への対応 l クラウドを使うことで不確実性に対応する l IaC:柔軟で再現可能なインフラストラクチャー l CloudFormaIon, AWS SAM, AWS OpsWorks l DevOps:より頻繁な改善、開発へのフィードバック l AWS Code(Commit, Build, Deploy, Pipeline), SecretsManager l マイクロサービス:疎結合なモジュールで変更が安全・容易に l Lambda, ECS (on Fargate), EKS l PoC:使った分だけ課金=初期投資不要、月数千円〜 l AWSのほぼ全てのサービス 24

Slide 25

Slide 25 text

クラウドプラットフォームが提供するサービス 25 l プラットフォームが提供する各種サービスをうまく使う l たとえばAWSの提供するIoT関連のサービスだけでもこれだけある l 150以上ものサービスがあり、随時追加・バージョンアップが行われている

Slide 26

Slide 26 text

業務効率化 l クラウドは効率化・コスト削減にも有効 l 開発効率の向上:DevOps基盤の提供 l DevOps基盤が整う→アジャイル開発がしやすくなる →変更に柔軟に対応できる→最終的な成果物までの道のりが短くなる l DevOpsをやらないと開発効率はあまり上がらないので注意 l インフラコストの削減:主として運用コスト l 使用率の最適化によりインフラ費用を削減できる l 運用・監視の自動化による運用コスト削減の恩恵が大きい 26

Slide 27

Slide 27 text

クラウド活用事例1:AWS大規模IoTプラットフォーム構築 l 世界各地の機器からデータを取得し分析 l 1日数億メッセージを受信する国内最大級規模のプラットフォーム l ロストしない・即時処理・スケーラブル 27 エッジサーバー デバイス IoT Core Kinesis ECS Fargate Aurora RedShift S3 Read Replica オンプレ データ受信層 データ処理層 データベース層 Auto Scale Auto Scale Auto Scale 生データ保管

Slide 28

Slide 28 text

クラウド活用事例1:AWS大規模IoTプラットフォーム構築 l 構築のポイント l IoTデータ(MQTTプロトコル)を扱うため、IoT Coreを中心としたIoT サービスを採用 l 主要なデータ経路であるエッジサーバーからデータを受けるために Kinesisデータキューを採用 l データ処理はECSでコンテナ化 l 上記全てを処理量に合わせたオートスケール対応 l DBは強力な処理能力を持つAuroraを使用し、かつ性能を出すために実 行が多い読み取り処理はリードレプリカに任せる l データ分析はRedShiftを採用し、Auroraに負荷を与えることなく独立で 実行 28

Slide 29

Slide 29 text

クラウド活用事例2:コンシューマー向け商品販売サイトリプレース l 改修・メンテナンスにコストがかかるようになっていたコン シューマー向け販売サイトを刷新 l 徹底的なサーバレスの採用で、サーバーを持たない構成に l CI/CDによる開発速度の向上 29 利用者 CloudFront Cognito API Gateway 認証基盤 ルーティング SPA 配置 S3 API管理 処理実行 Lambda DynamoDB CodePipeline CodeBuild 開発者 デプロイ Commit CI/CDフロー オンプレ

Slide 30

Slide 30 text

クラウド活用事例2:コンシューマー向け商品販売サイトリプレース l 構築のポイント l 構成はスタンダードなサーバレスアプリケーション l フロントエンド・バックエンドのデプロイを全自動化 l 環境構築もCloudFormationで自動化し、いつでも複製可能に l オンプレとの通信がAPI化されていることが明確だったため、リプレー ス領域のサーバレス化を早い段階で決定できた l 一方でオンプレとの通信経路の確立や社内ネットワークからの参照、 既存のネットワーク構成に則った構築など、思わぬ障壁も 30

Slide 31

Slide 31 text

クラウドプラットフォームの選定 l AWS l 実績が多く、エンジニアの調達が容易 l 既存のEC2・ネットワーク・アカウントを活用できる l GCP l ソーシャルゲーム領域など通信の多いサービスでよく使われる l G SuiteやGmailアカウントとの連携 l Azure l Windows ServerやAD・Office 365・Sharepoint等の連携に強み l 導入事例数ではやや劣る l NCDCでの案件数は AWS>Azure>GCP l AWSがやや強いが他のプラットフォームも増えてきている 31

Slide 32

Slide 32 text

まとめ l クラウドはDXの肝である不確実性への対応の基盤になる l 変更に強く、スピーディなインフラ構築 l サービス化された先端技術との連携 l 「EC2クラウド」を超えてクラウドネイティブな構成に l 「3つのハードル」をうまく乗り越える l 目的を明確にし、制約条件に注意する l クラウドのメリットを最大限引き出す 32

Slide 33

Slide 33 text

まとめ l DXの指針:まず始めよう l 小さく始めて大きく育てる l それを可能にするのがクラウド l 大事なことはやってみなければわからない l DXは新しいチャレンジ l やる前にわかることもある l システムと共に組織も変える l チームのあり方や個人の役割も変わってくる l システムを変えるなら組織も変わる 33

Slide 34

Slide 34 text

NCDC公式ホームページの「コラム」もご活用ください 34 関連する過去セミナーの資料 「DXを実現する組織とロードマップのつくり方」 https://ncdc.co.jp/columns/6798/ 「DXを成功に導くための3つのキーファクターとは」 https://ncdc.co.jp/columns/6496/ 「マネージャー層向けモダンアプリケーション開発戦略セミナー」 https://ncdc.co.jp/columns/6626/

Slide 35

Slide 35 text

お問い合わせは l info@ncdc.co.jpまで 35

Slide 36

Slide 36 text

① 対象のシステムの特性に依存します l クラウドの費用の特性は使った分だけ、という考え方 l 24時間・365日定常的に高い使用率の場合は、サーバー費用だけ見る とオンプレの方が安い場合があります l 逆にいうと使用率が変動するような場合では、大きく費用を下げるこ とができる可能性があります。 ただし!次ページ以降に続きます Appendix:クラウド移行でコストは下がる? 36 オンプレの場合、 ピークに合わせて リソースを調達 実際の使用率 クラウドの場合、 必要に合わせて リソースを追加、 削減が可能

Slide 37

Slide 37 text

Appendix:クラウド移行でコストは下がる? ② オンプレと同じ考え方では下がらない場合があります l 直近必要なだけのリソースを使用する見積もりにする l オンプレのサーバーでCPUの使用率がピークで10%台ということ、良くありま せんか?オンプレの場合、一度買ったサーバーを拡張するには時間がかかり ますので、予め2年後、3年後の処理量を予測して購入します。一方、処理 量が予測通り増えないこともよくあることです。 l クラウドの場合、リソースの追加はWeb管理画面から設定を 変更するだけになりますので、各種リソースの使用量の見える化と それに応じてリソースを追加できる予算取り、体制を準備しておきます l 必要に合わせてリソースを追加、削減できる仕組みにしておく l CPU、メモリなどのリソースの追加は比較的簡単にできますが、サーバーの 追加、削除までやる場合、事前にそれができるように設計しておく必要があ ります l インフラの設定だけではなく、アプリケーションとしてもそれができるよう に事前の設計が必要です 37

Slide 38

Slide 38 text

Appendix:クラウド移行でコストは下がる? ③ サーバーの費用と、AWSコストの比較だけでなく、 運用コストや開発に与える影響も加味して考慮する l 実際の運用には、サーバーの費用やAWSの費用だけでなく、 運用にかかるさまざまなコストや、人などのリソース、 ハードウェアが故障するなどのトラブルが合った場合の対応などを 考慮する必要があります。 38

Slide 39

Slide 39 text

No content