Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Seminar_AWSforDX_20201216

NCDC
December 17, 2020

 Seminar_AWSforDX_20201216

DX実現のためには、クラウドの活用とともに、システム開発のプロセスや体制の変革も必要です。
しかし、レガシーシステムを抱えた企業や、SIerに依存した開発体制をとっていた企業では、そうした変革の最初の道筋を見出すことが困難かもしれません。

本セミナーでは、「これからクラウドを取り入れたい」「単なるオンプレミスからの置き換えを止めてクラウドネイティブなシステムを目指したい」という考えをお持ちの方に向けて、目指すべき姿を実現するための、AWS活用法(クラウド活用法)を解説します。

マイクロサービス 、サーバレス、DevOps、CI/CD、SPA(Single Page Application)などの先進的な手法の導入方法(活用できるAWSのサービスやアーキテクチャの例)もご紹介しますので、これらのキーワードに関心のある方もぜひご参加ください。

※このセミナーでは具体例としてAWSを用いた解説をしますが、AzureやGCPなど他のクラウドサービスに置き換えて考えることもできる内容です。広く「クラウド活用」に関心のある方におすすめです。

NCDC

December 17, 2020
Tweet

More Decks by NCDC

Other Decks in Technology

Transcript

  1. 私たちにできること① l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い

    ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP(Minimum Viable Product)を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT / AR l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画 モックやプロトタイプ の開発・検証 開発 継続的な改善
  2. 私たちにできること② l 社内に最適な組織がない場合の組織づくりや⼈材育成から、⾼度な技術をもったエンジニ アによる技術移管まで、幅広くお客様をサポートします。 5 ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした 課題抽出・企画

    モックやプロトタイプ の開発・検証 開発 継続的な改善 企業のDXやデジタルビジネスの創出に必要なこうしたプロセスを多⾯的にサポート DX戦略⽴案 ⼈材育成 技術移管 リファレンス実装 DX組織構築⽀援 アジャイル導⼊⽀援 ⼿法や技術の選定 ブランディング
  3. Business 事業領域の推進 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • コンサルティング •

    新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI / AR • クラウドインテグレーション 6 NCDCのサービス体系
  4. 本日の内容 l DXにおけるクラウドの役割 l DXとは何か l クラウドの特徴 l DXにおけるクラウドの役割 l

    クラウド活用のポイント l クラウド活用の3つのハードル l 不確実性への対応 l クラウド活用事例 l クラウドプラットフォームの選定 l まとめ 7
  5. DXとは何か l DX= 先端技術を用いて、業務・サービスをデジタル化することで、 今までにない新しい価値の提供・業務効率化を行うこと l 先端技術: AI、IoT、クラウド、SPAなどの新しい技術、マイクロサー ビスやアジャイルなどの方法論 l

    今までにない新しい価値:先端技術で実現される、今までできなかっ た新しい体験・機能 l 業務効率化:引き続きITシステムにおける関心事項 l 単なるIT化の延長ではなく、新しい技術で新しい価値を届けるこ とがDXの文脈では求められている 9
  6. クラウドの特徴 l 高い拡張性 l 計算資源を柔軟に拡張可能 l 様々なサービスと連携 l 従量課金の課金体系 l

    使った分だけ課金される l イニシャルコストがゼロに近い l 構築・維持の外部化 l インフラ構築の具体的作業を意識する必要がなく、アプリケーション 部分に注力できる l プログラムによる自動化が容易 10
  7. DXにおけるクラウドの役割 l DXの最大のポイント:不確実性 l 新しい技術・新しい価値・変化の早い時代 l アジャイル的な手法が重視されるように l インフラ部分での変化への対応力を実現するのがクラウド l

    業務効率化においてもクラウドは大きな威力を発揮 l 開発効率の向上:DevOps基盤の提供 l インフラコストの削減:主として運用コスト 11
  8. 「EC2クラウド」からクラウドネイティブへ l 「EC2クラウド」 l AWS EC2やRDSをリモートサーバーとして利用 l 多くの企業で活用されているAWSの利用形態 l SIerを中心とした販売代理ベンダーが運用・維持

    l クラウドネイティブ l クラウドプロバイダーが提供するサービスをフルに使用 l コンテナ、サーバレス、AI、IoT、CI/CD、ライブストリーミング、etc… l 無数にあるサービスを有機的に組み合わせ最適なアーキテクチャを構 築する必要がある 14
  9. クラウド活用の3つのハードル 1. 適切な技術の選定 l EC2 + RDSでは不十分 l AWS東京リージョンには150以上のサービスが存在 l

    必要なものを適切に選ぶ l 使ったことのないサービスの方が多い → 手を動かす必要がある l Webサービスにおける標準はある程度定まってきている l 実際には、様々な制約から三者三様なアーキテクチャになる l 社内ネットワーク・既存システムとの接続 l セキュリティやアプリケーションの制約 l 期間・人材・将来的な戦略との兼ね合い 16
  10. クラウド活用の3つのハードル 2. クラウド活用の人材確保 l クラウド人材 ≒ DX人材と言っても過言ではない l クラウドエンジニアだけではダメ l

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

    → 安全側に倒して禁止 l 社内の壁 2:不確実性 l 試作しなければわからないことも多い → 確実な成果が見込めないとGoが出ない l 事前調査やPoCを十分に行わない、納期に余裕を持たない l 社内の壁 3:縦割り部署 l あのシステムは◦◦部、あそこのネットワークは××部、・・・ l アジリティ・柔軟性が下がる 18
  12. どうするか 1. 最新技術へのキャッチアップ l 社内に技術者がいるならそれに越したことはない l 各メンバーが自主的に情報収集する l 皆さんのことです l

    アプリ開発者、クラウドエンジニアと会話できるレベルでは理解しておく l 自社のシステム構成やインフラ構成の概要をしっかり説明できますか? l 外部リソースを活用する l NCDCのことです l 技術を持っている会社は多いが、適切に力を借りるのは難しい l 「自分たちも何をやりたいかわかっていない」ことがよくある (決して悪いことではなく、DXの特性として) l クラウド移行を試す 20
  13. どうするか 2. アジャイルを中心としたチームビルディングと人材戦略 l 一人で全領域をカバーする必要はない、チームでカバーできればよい l アジャイルにおけるチームづくりが参考になる l 様々な役割を持つメンバーが上下関係なく意見する l

    お互いがお互いの領域に関心を持つ l 開発はベンダーさんにお任せ、ではうまくいかない l 柔軟に動いてくれるか協力会社を見極める l なんでもイエスと言ってくれるということではない l DXを推進できる人材を社内で育てる l 事業会社の場合、エンジニアが足りていないことが多い l エンジニアがいない場所にエンジニアは来ない 21
  14. どうするか 3. ある程度トップダウンで巻き込む l 社内制度や権限については上位層が動いてくれないと厳しい l 自分たちの挑戦に価値があると経営層を納得させる説明ができるか? l 小さく始めて成果をつくる l

    他社事例や外部の意見を持ち込んで説得する l 巻き込む範囲はなるべく広く、巻き込む人はなるべく少なく l 社内に広く協力してもらう l 意思決定の人数が増えると動きが鈍るので、決済者を巻き込む l セキュリティや不確実性に関しては論理武装を l GoogleやAmazonより高いセキュリティが必要ですか? 22
  15. 不確実性への対応 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
  16. クラウド活用事例1:AWS大規模IoTプラットフォーム構築 l 構築のポイント l IoTデータ(MQTTプロトコル)を扱うため、IoT Coreを中心としたIoT サービスを採用 l 主要なデータ経路であるエッジサーバーからデータを受けるために Kinesisデータキューを採用

    l データ処理はECSでコンテナ化 l 上記全てを処理量に合わせたオートスケール対応 l DBは強力な処理能力を持つAuroraを使用し、かつ性能を出すために実 行が多い読み取り処理はリードレプリカに任せる l データ分析はRedShiftを採用し、Auroraに負荷を与えることなく独立で 実行 28
  17. クラウド活用事例2:コンシューマー向け商品販売サイトリプレース l 構築のポイント l 構成はスタンダードなサーバレスアプリケーション l フロントエンド・バックエンドのデプロイを全自動化 l 環境構築もCloudFormationで自動化し、いつでも複製可能に l

    オンプレとの通信がAPI化されていることが明確だったため、リプレー ス領域のサーバレス化を早い段階で決定できた l 一方でオンプレとの通信経路の確立や社内ネットワークからの参照、 既存のネットワーク構成に則った構築など、思わぬ障壁も 30
  18. クラウドプラットフォームの選定 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
  19. まとめ l DXの指針:まず始めよう l 小さく始めて大きく育てる l それを可能にするのがクラウド l 大事なことはやってみなければわからない l

    DXは新しいチャレンジ l やる前にわかることもある l システムと共に組織も変える l チームのあり方や個人の役割も変わってくる l システムを変えるなら組織も変わる 33
  20. ① 対象のシステムの特性に依存します l クラウドの費用の特性は使った分だけ、という考え方 l 24時間・365日定常的に高い使用率の場合は、サーバー費用だけ見る とオンプレの方が安い場合があります l 逆にいうと使用率が変動するような場合では、大きく費用を下げるこ とができる可能性があります。

    ただし!次ページ以降に続きます Appendix:クラウド移行でコストは下がる? 36 オンプレの場合、 ピークに合わせて リソースを調達 実際の使用率 クラウドの場合、 必要に合わせて リソースを追加、 削減が可能
  21. Appendix:クラウド移行でコストは下がる? ② オンプレと同じ考え方では下がらない場合があります l 直近必要なだけのリソースを使用する見積もりにする l オンプレのサーバーでCPUの使用率がピークで10%台ということ、良くありま せんか?オンプレの場合、一度買ったサーバーを拡張するには時間がかかり ますので、予め2年後、3年後の処理量を予測して購入します。一方、処理 量が予測通り増えないこともよくあることです。

    l クラウドの場合、リソースの追加はWeb管理画面から設定を 変更するだけになりますので、各種リソースの使用量の見える化と それに応じてリソースを追加できる予算取り、体制を準備しておきます l 必要に合わせてリソースを追加、削減できる仕組みにしておく l CPU、メモリなどのリソースの追加は比較的簡単にできますが、サーバーの 追加、削除までやる場合、事前にそれができるように設計しておく必要があ ります l インフラの設定だけではなく、アプリケーションとしてもそれができるよう に事前の設計が必要です 37