概要
B2C アプリケーションプラットフォームの構築を支援。独自技術による高度な UX を提供可能なプラットフォームの実現を目指している。プラットフォームの構想段階から支援し、ビジネスユースケースの整理、実現したいアイデアの実現方針策定を担当。独自技術をどのようにコンポーネント化してプラガブルに組み合わせるか、クラウドネイティブアプリケーションのベストプラクティスを適用した設計の支援を実施している。
ソフトウェア開発の知見を強みとして、クラウドベンダーと顧客要件を繋いだり、DevOps 導入やクラウドベンダーがタッチしないアプリケーションアーキテクチャ面を支援している。
顧客の目的
- B2C アプリケーションのプラットフォームを構築する
- プラットフォームは、認証・認可・課金・ログ収集などの共通機能を提供するとともに、対話型 UX を持つアプリケーション開発を容易にするためのコアサービスを提供する
- コアサービスには独自技術も活用されており、R&D の成果を現実世界に適用する橋渡しとする
- アプリケーションクリエータがシステム非依存で高度な UX を設計・実現することを可能にし、イノベーティブな製品開発を促進させる
支援方針
- ソフトウエアエンジニアリング、業務モデリングをベースとした設計アドバイス
- ライフサイクルや変更頻度や程度を基準にしたシステムコンポーネントの分割、API 設計
- 少人数運用に耐える DevOps の実現。既存の障害管理システムとの統合
- AWS Well-Architected Framework などに即した AWS Native なシステム設計の支援
- The Twelve-Factor App を念頭に置いた設計
課題とソリューション
頻繁な機能改善要求・開発期間の短期化
- エンドユーザ向けに直接価値を提供するサービスは、それぞれ機能ごとに個別のサブプロジェクトとして実施。開発効率の向上と、きめ細やかでスピード感のある改善が可能に。ただし統合が困難になるので下記の設計指針を適用
- プラットフォームの API や役割を明確化し、サービス開発時に依存してよい事柄を明確に定義
- プラットフォームや共通機能のリリースとは独立したライフサイクルでリリース可能な CI/CD 設計
- プラットフォームや共通機能もサブモジュールとして個別に開発。（別リポジトリ）
- システム全体の依存関係の整理。単純化
- 個別のコンポーネントの信頼性（品質基準・とくに耐障害性と障害発生時の挙動の明確化）を高くし、障害伝搬を抑制
学習コストを抑えたい、Ease Of Development の実現
- クラウドベンダー技術に依存してよいこと、非依存にしておくべき範囲を設定
- スタンダートな設計ポリシーの適用。（Wel-Architected FW)
- マルチクラウドベンダーではなくシングルクラウドベンダー(AWS)を採用
- ベンダー固有の専門的なサポートを受けられる
- 開発者の学習範囲が限定され、知識の共有化が促進される
- 段階的な自動化の適用
- 影響範囲の狭い範囲においては、自動化の適用を少し遅らせることも許容。ただし、運用段階になれば自動化を進める
ソースコードの社外サーバ保存禁止制約
- 一部の社内開発ライブラリについては、ソースコードの社外サーバ（GitHub/AWS Code*）への保存禁止制約への対応を実施し、イントラネット内のビルド環境と、社外（AWS）のテスト環境・品質確認環境・ステージング・商用環境を統合したデプロイパイプラインを構築。（半自動）
エンドユーザのニーズ(需要）が読み切れない
- サーバレス化の推進。=> 負荷に対する弾力性を確保。低コスト開発の実現
- 非機能要件の大部分をインフラから享受できるような、標準的なサービスモジュールの組み合わせを推進
運用のセキュリティ設計・開発の効率化
- AWS のアカウント・ロールによる統一的なセキュリティ戦略の適用
- 開発・テスト環境には開発者の強力な権限を付与、運用環境には厳格な制限を適用
- インフラのコード化により、全ての環境の構成差分を管理可能に
今後の展望
計測に基づくコストマネジメントの実施
- インフラリソース・サービスの効率的な活用
- 継続的な自動化の推進による管理工数削減
適用技術
運用・移行設計
- ITIL
- Amazon CloudWatch/JIRA 連携
開発言語
- Python
- Node.js
インフラ環境構築
- AWS CloudFormation
デプロイ
- AWS CloudFormation / AWS CodeDeploy / Jenkins
CI
- Jenkins
- CodeStar
Load testing
- JMeter
