クラウドトランザクション

クラウド構築


はじめに

弊社では、主に、AWS（Amazon Web Services）を用いたクラウド構築を実施しています。AWSは、世界的に最も普及しており、日本政府でも大規模に導入されている信頼できるクラウド環境です。データセンター（DC）は世界中に存在し、日本国内のDCを選択することも、海外を選択することも可能です。


構築は、以下のスケジュールに沿って進めるのが一般的ですが、プロジェクトの特性によっては、一部の工程を省略することもあります。
各工程ごとに、お客様と弊社の間で、最低２回（開始前後）のレビューを開催いたします。

アセスメント


弊社では、次の観点からアセスメントを進めます。そして、お客様の環境に最もフィットした構築（移行）計画書を作成いたします。（一部、ITコンサルティングに含まれる作業があります。）

項目 新規 マイグレーション
現行課題の明確化 ○ ○
課題解決策の妥当性 ○ ○
現行システムの特性 ○
ステークホルダーとその期待レベル（稼働後の作業負荷含む） ○ ○
対象プロジェクトの範囲と期限 ○ ○
インフラ上の制約（電力、ネットワーク、端末等） ○ ○
リスクとその対策 ○ ○
業務特性（成長性、迅速性、時限性） ○ ○
システム特性（アクセス特性、負荷変動、ロケーション） ○ ○
利用するアプリケーションの特徴、利用方法、ライセンス ○ ○
最適なリソース配置案の再検討（サーバ配置、アプリケーション配備、NW等） ○ ○
セキュリティポリシー（機密性、完全性、可用性） ○ ○
セキュリティ対策のレベル比較と費用対効果 ○ ○
DR（Disaster Recovery）方式 ○ ○
効果測定方法と効果目標 ○ ○
運用体制の計画 ○ ○
予算及び費用の扱い ○ ○



PoC（Proof of Concept）


PoCを実施するにあたっては、クラウド環境がきわめて有効です。AWSには、一定期間無料のサービスや、規模に応じて柔軟にスケールアウト/イン（又はスケールアップ/ダウン）できる仕組みが備わっているため、PoCでの検証ポイントさえしっかり計画すれば、短期間・低コストでのPoC実施が可能となります。

  • PoC実施準備として、簡単なアプリ、API、スタブなどが必要な場合は、Node.js（JavaScript）、AWS API Gateway、Lambda関数などの弊社の得意とする技術でスピーディに対応します。

  • PoCの過程で、負荷試験に使用されるJMeterの技術を利用して、あらかじめ予想される負荷状況や負荷パターンを作り出し、ビジネスや業務におけるリスクや必要機能を洗い出すことも可能です。

  • PoC実施の過程で得られたデータに対し、AWSのKinesis、Athena、EMR、Redshift、SageMakerなどの分析ツールを活用すれば、より多くの知見が得られ、PoCの効果が高まります。

基本計画


基本計画は、PoCで見込まれた効果に対して、概算費用や構築期間などのプロジェクト規模を把握するために実施されます。また、これによって、セキュリティ上の受容範囲やシステムの限界などが把握できます。 プロジェクトごとに異なりますが、経験上、主な決定項目は以下の通りです。

  • ステークホルダー（ロール）ごとの利用形態（業務フロー等）
  • 対象システムの負荷傾向（予測）
  • クラウド利用形態（SaaS/PaaS/IaaS）
  • アカウント構成（本番/ステージング/開発ごとの分離、請求合算等）
  • クラウドの運用・保守方式（HAクラスター、CI/CD等）
  • セキュリティ対策（NWレイヤごとの対策、ログイン方法等）
  • 障害対策（HAクラスター、バックアップ等）、DR（Disaster Recovery）
  • ビジネスの成長や負荷変動に応じたスケールアウト/イン・スケールアップ/ダウン方式
  • データのサイズ見積り、保存方法、保存期間、利用方法
  • ネットワークトラフィックの見積り
  • データ採取・加工・分析方法
  • 概算費用

>¶ HA（High Availability）クラスターには、負荷分散型とフェールオーバー型とがあります。

設計


基本計画に基づき、AWS等クラウドサービス上での具体的な実装方法を決定します。これによって、より正確な費用が算出されます。クラウド上のサービスの選択や利用方式によって、基本計画で求めた概算費用が大きく変動することがあります。次のような項目を決定します。

  • ネットワーク構成（CDNの有無、リージョン選択、AZ構成、サブネット構成、HAクラスター方式、FW方式、WAFの有無、SSL/TLS実装方法等）AZ：Availability Zone
  • DB選定（RDB、NoSQL、マネージドレベル）
  • ストレージ構成
  • 監視・監査・ログの測定周期、監視周期、アラーム設定とアラート先、タイムアウト値等
  • 障害対策（HAクラスター方式、バックアップ方式・タイミング・世代管理、リカバリ方法）
  • 費用低減対策
  • 詳細費用

設計方針

ひとつの機能を実装するにあたって、いくつかの実現手段がありますが、弊社では、常に、以下を意識したベストプラクティス、即ち、その時点で最も優れており、かつ、将来に渡って主流となるであろう手段を模索して、それを利用しております。

  • セキュリティ・安全性
  • レスポンスの速さ
  • 変更の柔軟性
  • 保守の容易さ
  • コスト



構築


上記の設計までの工程で、お客様と弊社とのコミュニケーションに齟齬が無ければ、構築は問題なく進められます。要件によっては、設計を再検討することもあります。

構成例

ベストプラクティス

  • 上の図は、開発環境と本番・ステージング環境のアカウントを分離した場合の構成です。
  • セキュリティを重視して、本番・ステージング環境のサーバをプライベートサブネットに設置する構成となっており、弊社推奨案です。
  • ディプロイは、AWS CodePipeline・CodeBuild・CodeDeployを利用して実施されます。

試験


試験の内容については、主に、可用性やセキュリティの観点から、以下のような項目を試験します。AWSの基本機能を確認するのではなく、各機能要素の設定や組合せが正しく行なわれ、協調して動作し、その結果が可視化されて確認できることが重要と考えております。

  • WAF IPブロック
  • 不正アクセス対策
  • SSL安全性
  • Webサーバ（EC2）フェールオーバー・フェールバック
  • Webサーバ（EC2）バックアップ・リカバリ
  • DBサーバ（RDS等）バックアップ・リカバリ
  • DBのPITR（point-in-time Recovery）
  • ロードバランサの維持設定（スティッキーセッション）
  • ログ出力
  • アラーム出力
  • ディプロイ
  • 負荷試験

負荷試験については、サーバのサイジングやスケールアップ/ダウン（若しくはスケールアウト/イン）計画とも関連するため、この結果を設計や構築のフェーズへフィードバックすることもあります。また、アプリケーションソフトの負荷脆弱箇所が判明し、ソフトウェア修正が必要となる可能性もあります。



移行・導入準備


移行計画は、早めに立てておく必要があります。 プロジェクトの特性に応じて、次のパターンになると思われます。

  • 全データを移行
  • 一部のデータを移行
  • データ移行無し

また、移行前の状態が紙のデータの場合や、データのアップデートが必要となる場合等、様々な状況があると思われますので、データ移行ツール選定、ツール作成等も含めて、構築案件とは別に、ご相談にあずかります。

導入計画は、人材のオペレーション訓練も含め、期間的に余裕をみて設定します。 弊社のコンサルティング契約の範疇となります。

移行


移行に際しては、できるだけ短期間で終えるように、事前に、切り戻し条件や方法を含めて、充分練り上げた計画を作成して実施します。

運用・保守


運用は、各ステークホルダーへの影響を充分に考慮して、なるべく定期保守の期間を取るようにします。対外的に問題となる場合は、事前に、SLA（Service Level Agreement）を作成して、先方と合意しておきます。
法務的な条件については、弊社は専門ではありませんが、技術的な条件については、検討を進める際のお役に立てると思います。
また、運用に当たっては、システムの利用規約の作成、個人情報保護法への配慮、万一情報漏洩があった場合の対応手順などが必要となりますが、これについても、あらかじめ検討・決定しておく必要があります。
さらには、運用体制の一部として、カスタマ対応窓口の設置なども検討する必要がありますが、弊社では、そのようなご相談にも対応可能です。

【お問い合わせ】 (opens new window)