1. アーキテクチャー
1.1. 参考アーキテクチャー
エクメルンでは以下のアーキテクチャー、デザインパターン、方法論を参考にしました。
- スケーラブル
- Design for Failure
- Infrastructure as Code
- Immutable Infrastructure
- マイクロサービス
- サーバーレスアーキテクチャ
- Reactive Programming
- The Twelve-Factor App
1.2. 設計ポイント
エクメルンでは以下のポイントを設計に反映しました。
1.2.1. HA構成
1.2.2. スケールアウト
特にエクメルンが利用する (AWS以外の) 外部サービスが1アカウントでは大量にリクエストを受け付けられない (もしくは制限がある) ケースがありうると考え、外部サービスを複数アカウント取得してスケールアウトできるように設計しました。
1.2.3. 非同期処理
1.2.4. サーバーレス化
1.2.5. 処理の中断・再開
メンテナンスやエラー、障害に備え、gracefulな処理の中断とすばやい再開が行えるようにしました。
1.2.6. BGデプロイ
1.2.7. 環境差分の最小化
環境差分や秘密情報 (アクセスキーなど) は別コンポーネントからパラメータとして注入するようにしました。
1.2.8. ログの集中管理
ログを1箇所のサーバに集める構成から、Amazon Kinesis Firehoseを用い、サーバレスでストレージに保管するようにしました。
1.3. クラウドサービス選定
1.3.1. 選定ポイント
クラウドサービスの選定ポイントは以下の通りです。
- 特徴コンセプトや機能 (APIやSDKも含む) を調べます。
- 価格
- 事例ビッグクライアントが利用しているかどうかだけでなく、勢いのある会社が利用しているかどうかもみます。
- 運営会社設立や社員数、資本金、業績を確認して、発展性や継続性を見極めます。
- 情報量公式ドキュメントやヘルプ、書籍数、ネット上の情報量を収集し、開発が行いやすいかを確認します。
- セミナー参加直近でセミナーがあれば参加し、ざっと製品の特徴や機能の概要を把握します。
- 実利用ざっと触ってみて使い勝手がよさそうかを確認します。
- サポート問い合わせ実際にサポート問い合わせを行いその対応をみます。
- ビジネス選定することで自分たちが市場で有利に戦いやすくなることがありえるかを検討します。 (たとえばお互い良きビジネスパートナーとなれる、などです)
- 営業マンに相談営業マンと直接話をしてみます。価格交渉の余地や特別なサポート、上記のビジネス的な話がありえるのかも聞いてもいいかと思います。
- 使いたいかどうかデベロッパーの気持ちも大切にしたいものです。
1.4. 選定後
選定したあとは必ず理由をドキュメントに書き残しておきます。
- 社内への説明が明確になります。
- 新メンバーが参入した時の引き継ぎに利用できます。→ 新メンバーが明確な選定理由のないサービスの利用でモチベーションがダウンすることも防ぎます。