なぜ多くの企業がクラウドの導入・活用推進に苦戦するのか？ 注意点と対策を解説。

すでに多くの企業が何らかのかたちでクラウド（AWSなどのパブリッククラウド）を活用していますが、新規導入や、より積極的なクラウド化の推進には苦戦しているケースが多々あるようです。

本セミナーでは、なぜ多くの企業がクラウド化の推進に苦戦するのか、その背景とよくある課題を整理して、クラウド戦略を成功に導くためのヒントをご紹介します。

主な内容
・クラウド利用に適しているシステムとは
・クラウドの特性を活かした最適な構成（アーキテクチャ）の検討
・最適なパブリッククラウドの選定方法
・システムと共に変わっていく組織のあり方
・コストの最適化

クラウドネイティブな環境の代表格であるサーバレスアーキテクチャに精通するコンサルタントを講師として、クラウド利用のメリットから、クラウド活用の成功事例まで幅広くご紹介します。

これから新規システム開発に取り組む方にも、既存システムのアーキテクチャ見直しに取り組みたい方にもお勧めの内容です。

Transcript

1. なぜ多くの企業がクラウドの 導入・活用推進に苦戦するのか？ NCDC Onlineセミナー 2024年7月30日 NCDC株式会社 〜注意点と対策を解説〜
2. 三浦 洋平 マネージングアーキテクト NCDCでは、 AWSアーキテクチャコンサル ティングを中心として様々なプロジェクト に従事。 AWSの大規模IoTプラットフォーム構築に加 え、JavaScript(React)を主としたフロントエ ンド開発、スマートフォンアプリ開発も経 験し、フロントからインフラまで幅広い領 域に対応できる技術力を持つ。
3. 3 NCDCのサービス体系 Business 新規事業⽴ち上げからの伴⾛ 業務改⾰やIT改⾰の⽀援 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation • 新規サービス企画 • PoC⽀援 • デザイン思考 • UX/UIデザイン • モバイル・Web先端技術 • IoT / AI • クラウドインテグレーション
4. 知識、経験、および実績 に基づく認定 クラウドに関する強み 4 自社運営で培った豊富な AWSのノウハウ NCDCは、内製化支援推進AWSパートナー、 サーバーレス（AWS Lambda）のサービス デリバリーパートナーなど AWS利用の知識、経験、 および実績に基づく認定を 取得しています。 AWSサービスデリバリープログラムとは、特定のAWSサービ スをお客さまに提供する上で深い技術的知識、経験、および 実際の成功事例があるAWSパートナーをAWSが認定するプロ グラムです https://aws.amazon.com/jp/partners/programs/service-delivery/ NCDCは、AWS上で稼働する自社サービス も提供しており、システム開発からサー ビス運営まで行っています。 サービスを自社運営する中で長年蓄積し てきたノウハウを基に、コストの最適化 から、AWSの多様なサービスをフルに活 用するクラウドネイティブなアーキテク チャの設計まで、実践的なサポートを行 います。
5. NCDCが支援したクラウド事例（ライフネット生命保険株式会社） 5
6. 本日のテーマ
7. 今日のテーマ l クラウドが難しいのは、今までのシステム構築とは全く異なる考 え方でシステム構成（アーキテクチャ）を考える必要があるから l クラウドの良さを最大限生かすには、クラウドの特性を活かした 最適な構成（アーキテクチャ）が必要 l 数多あるクラウドサービスの中から最適なサービスの選定ができ るかがクラウド化の成功のポイント 7
8. 目次 l クラウドが難しいのはなぜか l クラウドの良さを理解する l クラウドの良さを活かすアーキテクチャ l アーキテクチャとは l よいアーキテクチャの考え方 l クラウドの特性を活かしたアーキテクチャの例 l クラウドサービスの選定 l クラウド化を困難にする「自社の事情」 l アーキテクチャの検証とアジャイル的プロセス 8
9. クラウドが難しいのはなぜか
10. 旧来のインフラ構成 l Webサーバー・アプリケーションサーバー・DBサーバーの3層構成 など 10 Webサーバー APサーバー DBサーバー 監視サーバー バッチサーバー …など
11. クラウドをフル活用したインフラ構成 11 l AWS Lambdaを駆使したサーバレス構成
12. クラウドはアーキテクチャの考え方が大きく異なる l クラウドに最適化したアーキテクチャ設計は、従来のサーバー単 位で考える構成と大きく異なる l どのサービスをどのように配置するか l どのようにサービス同士をつなげるか l データを持つ部分はどこか l …etc l 考え方が異なるので、今までの延長線上でやっても上手くいかな い l より細かい単位で機能が分割できるので、サーバー1台でなんでもや るという考え方からは脱却する必要がある 12
13. クラウドの良さを理解する
14. クラウドの良さ l 変更に対する柔軟性・拡張の容易性 l 物理的なサーバーに依存しないため変更・拡張が容易 l 運用の低コスト化 l 物理サーバーの管理からの解放、OSレベルのメンテナンスの削減 l 多種多様なサービス利用による実装負荷軽減 l キューによる非同期処理、通知やデータ同期、自動デプロイなど →自分達で作るのは難しい 14
15. なぜクラウドを使うのか？ l クラウドにどんなメリットを期待するか？を明確にする l クラウドの特性をフルに活かした最適な構成を組まないとメリットが 最大限享受できないことも多い l 「サーバーコストの低下」は叶わないことも多い l 対象のシステムが恩恵を受けることができるかどうかは慎重に見 極める必要がある l ただクラウドに持っていくだけではクラウドの恩恵を受けきれないこ とはよくある 15
16. クラウド利用に適しているシステム l 「クラウドに置くことが向いてない」システムは今やほとんどな い l 一方で、クラウド移行のメリットが感じづらいシステムは存在する l 多様なマネージドサービスを使えることがクラウドの魅力のため、 機能をそのまま移行する場合はメリットを感じづらい l EC2にそのまま移行する場合 l →実行基盤をコンテナにして、ECSに載せれるのならメリットあり l 新規システムはクラウドに合わせて設計できるため、メリットの 享受は容易 16
17. クラウドの良さを活かすアーキテクチャ
18. アーキテクチャとは l どの要素をどのように組み合わせてシステムを構成するかを決め たもの l クラウドにおいては、どのサービスを使うか（サービス選定）とその 組み合わせの方法を指す l ≒インフラ構成図 18
19. 良いアーキテクチャの考え方 19 l アーキテクチャに正解はない l ただし、よく使われるアーキテクチャのベストプラクティスはあ る l 他社のアーキテクチャの事例がヒントになる l AWS公式など NCDCのホームページにもいくつか載っています l システムの機能要求・自社の制約事項によって最適なアーキテク チャは異なる l 試行錯誤してアーキテクチャを決める必要がある
20. AWS Lambdaによるマイクロサービスの実装と、CI/CDによるDevOpsの実現 20
21. Amazon Kinesisで数億メッセージを毎日処理するIoT基盤 ① Amazon Kinesisシリーズの活 用でデータロストなし・処 理のオートスケールが可能 ② 生データと業務に必要な データ処理を分離 ③ アプリ側はリードレプリカ で負荷を分散 ④ 分析側はAmazon Redshiftで 集計を最適化 IoT機器 Amazon Kinesis Amazon ECS Amazon Kinesis Amazon ECS Amazon Aurora Amazon Kinesis Data Firehose Amazon S3 Amazon Athena AWS Batch Amazon Redshift アプリへ 分析 生データ抽出 データレイク アプリ処理層 一次加工
22. クラウドサービスの選定
23. クラウドサービスの選定 23 l ECS, ECR, RDS, Lambda, DynamoDB, S3, CloudFront, Amplify, ALB, Cognito, API Gateway, CodeBuild, CodePipeline, Secrets Manager, VPC, VPC endpoint, EC2, (IAM, Security Group) l 一般的なWebシステムであればこのあたりを把握しておけば何とかな る l よりクラウドの特徴を活かしたシステムにする場合、特定の領域が追 加になっていく l バッチ、非同期処理、IoT、ストリーミング、生成AI、ビッグデータetc →クラウドサービスの選定は難しい
24. クラウド化を困難にする「自社の事情」
25. さまざまな制約の存在 l セキュリティによる制約 l データは全て日本になければならない l （たとえ暗号化されていても）インターネットを通ってはならない l 会社のルールによる制約 l すでに用意されている自社ネットワークの上に構築する l 特定のサービスは使用不可 l 開発者が自由にクラウドサービスを触れない l 非機能要件による制約 l バックアップを複数持つ必要がある l 処理は何秒以内に返す必要がある・何分以内に終える必要がある l コストの問題 25
26. クラウド活用に合わせて変わっていく組織のあり方 l クラウドの利活用に組織のルールが追いついていない場合が多い l 開発者がクラウドを触らない前提になっていることが多い →実際は試行錯誤が必要なため、開発者もクラウドを触ることが多い l 厳しすぎるセキュリティルールやネットワークルール l 見直しは難しいが、できるとやりやすくなる l どこがネックになるかはプロジェクト次第 l プロジェクトメンバーが都度ルールを作る側と話し合えるのが理想 l ルールは変えていくもの、という意識が企業側に必要 26
27. クラウド化を上手く進めるための2つの方法
28. クラウド化を上手く進めるための2つの方法 l 知見を持った専門家に頼る l NCDCがクラウド化をお手伝いする意義 l トライアンドエラーを繰り返す l 「使ってみないとわからない」は案外多い l アーキテクチャの検証期間を設けた方がよい 28
29. アーキテクチャの検証とアジャイル的プロセス
30. 検証プロセスを回す l プロジェクト開始時は、アーキテクチャは「仮説」である l 実装の中で（機能の実装と一緒に）、アーキテクチャを変更して いく l クラウド構築はインフラベンダー・クラウドベンダーの仕事では なく、開発チームとの共同作業になる l 仮説検証を繰り返すため、アジャイル的アプローチと相性が良い l ウォーターフォール的にやるのは相性が悪い 30
31. 検証プロセスを回す l プロジェクト前の段階で、アーキテクチャのPoCを実施することも 有効 l 実現可能性や性能・コストをあらかじめ測定しておく l そもそも作ったアーキテクチャがきちんと動くか調べる l コストや性能は事前に計算し切ることが難しいため、PoCでシミュ レーションしておくことが望ましい l データの量が多くなると予期せぬ制約が出てくることも l PoCでリスクを潰しておけると◎ 31
32. 本日のまとめ
33. 今日のテーマ l クラウドが難しいのは、今までのシステム構築とは全く異なる考 え方でシステム構成（アーキテクチャ）を考える必要があるから l クラウドの良さを最大限生かすには、クラウドの特性を活かした 最適な構成（アーキテクチャ）が必要 l 数多あるクラウドサービスの中から最適なサービスの選定ができ るかがクラウド化の成功のポイント 33
34. 本日のまとめ l クラウドサービスの選定にはノウハウが必要 l 会社ごとに制約事項が異なる l 制約事項を変えていく試みも重要 l アジャイル的アプローチでアーキテクチャを考えていくことが重 要 34