# クラウドアーキテクト・ファーストステップ　振り返り
## mod.1
### サービスモデル
- 自分たちが責任を持つ範囲を明確にした上でサービスモデルを決める
- アプリケーションの開発と改善に注力するのであれば、IaaSを選択するケースは少ない
### DXとの関係
- DXはデジタル（ソフトウェア）の力を使って人々の生活をよくすること
- ソフトウェアは、バージョン1の時点から顧客に受け入れられる（社会に浸透する）というのは稀で、何度も改善を加えて成功することが多い
- ソフトウェアの改善サイクルをあげることが必要 ＞ クラウドのような柔軟な基盤が向いている
- DXを実践し顧客にリーチする企業は、SIerに頼らず内製ケースが増えている。クラウドにより、インフラの調達にも苦労することがなくなった
- インテグレータは、顧客から言われたものを請け負い作成するのではなく、顧客が必要とするものを、クラウドの特性を活かして「共創」する必要がある
## mod.2
### 抽象化とAPI
- クラウドで提供される機能の全ては、クラウドのAPIで提供されている
- APIにより抽象化され、クラウドの利用者はクラウドの中身の詳細を知らなくとも「自分が欲しい機能」をAPIを使って利用できる
- Webコンソール、CLI、コードからの利用、の全てがAPIを経由してクラウドを制御している
### インフラをAPIで制御できることのメリット
- インフラをコードから制御できるので、運用の自動化や大規模環境の複製などが簡単にできる（Infrastructure as Code/IaC）
- 誰が、いつ、どのサービスを、どう使ったかの認証・認可と、ログ（証跡）が取れる
### 仮想マシン(VM)
- 柔軟性が高くコスト管理もしやすいインフラ
- アプリケーションの稼働に関係なく課金される
- 常に動作し続ける必要のある環境には向いているケースも多い
### コンテナ(Docker)
- アプリケーションとその実行環境を閉じ込めたもの
- VMに比べ、軽量で起動や停止が早く高速なスケーリングが可能
- Dockerのインストールされた環境であれば、コンテナはほぼ間違いなく動作するため、アプリケーションの移動先の構築作業が不要＞素早いリリースサイクルを維持できる
- アプリケーション開発者が、アプリケーションの実行環境をDockerfileで用意できるため、インフラエンジニアの稼働時間を無駄にせずにすむ
### FaaS（サーバレスコンピューティング）
- 関数（アプリケーションの部品）単位でデプロイし、関数が実行されたときだけ課金されるインフラ
- リージョン、言語、トリガー（実行のきっかけ）だけ設定すれば利用可能で、可用性が高くスケーラブル
- 時間・APIの呼び出しなど、何かをトリガーに単発で動作する環境に強いが、長時間の連続実行には向かない
### データベース
- リレーショナルデータベースの運用負荷軽減のために、マネージドサービスを使う。ストレージの自動増減、日次バックアップ、ミドルウェアのパッチ当てなど日常のメンテナンス作業を行なってくれる
#### BASE特性とNoSQL
- 整合性（一貫性）よりも可用性を重要視したデータベース
- 分散構成で複数のデータベースサーバーが同時に稼働することで可用性とスケーラビリティを提供する
- 一時的にデータが不整合になることを許容する（結果整合性・結果一貫性）
- 一般的には、NoSQLと呼ばれるカテゴリで提供されている。以下の特徴がある
- トランザクションの保証がない（一部持つものもある）
- 外部キーによるテーブル間連携の機能がない（コードで連携する）
- 高いパフォーマンスを誇り、低コストで運用できることが多い
## mod.3
### クラウドネイティブ
- クラウド（特にマネージドサービス）のメリットを活かして、開発と改善に集中すること
- コンテナの活用、サーバレスコンピューティングへの移行、監視サービスをクラウド上のサービスに移行する、など
### マイクロサービスアーキテクチャ
- アプリケーションの構成要素をマイクロサービスと呼ばれる小さな部品に分割し、それらをAPIで連結させる構成
- 各要素はAPIのみ連携可能なため、APIを変更しなければ各要素の変更を自由に行える＞変更に強い
- API単位での開発、テスト、リリース、スケールが可能で、インターネット上の変化や変更の激しいアプリケーションに向いている