View
0
Download
0
Category
Preview:
Citation preview
AWSにおけるプロビジョニング
ＩＴライブラリーより （pdf １００冊）http://itlib1.sakura.ne.jp/
解説
（全１２０ページ）
1
本資料の関連資料は下記をクリックして
ＰＤＦ一覧からお入り下さい。
ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/
目次番号 ４５３番 ＡＷＳ詳細解説 全３３冊 計６,１００ページ
2
3
補足： プロビジョニング 【 provisioning 】
プロビジョニングとは、ユーザの需要を予想し、設備やサービスなどの
リソースを計画的に調達し、ユーザの必要に応じたサービスを提供できる
ように備える行為の総称。
4
複数のサーバやネットワーク、アプリケーション、ストレージなどの
リソースを仮想化によって 一つのコンピュータリソースとみなし、
ユーザから要求があった場合や障害時などに、必要な分だけ、
コンピュータリソースを動的に別のシステムに割り当てられる ように
すること。
5
補足： デプロイ 【 deploy 】
デプロイとは、配備する、配置する、展開する、配置につく、などの意味を
持ちます。
ソフトウェアの分野で、開発したソフトウェアを 利用できるように実際の運用
環境に展開することを デプロイということがあります。
6
インストール（install）に近い意味ですが、サーバコンピュータ上で運用され
外部からネットワークを通じて利用されるソフトウェアや、他のソフトウェア
から参照されるコンポーネントなどを、利用可能な状態にする、アクセス
可能にする、といったニュアンスがあります。
7
8
9
10
11
12
13
14
コードによるインフラ基盤の記述
15
本番稼働している インフラの設計書やサーバのパラメータシートが、実際の
設定値と異なって、いざ環境を構成変更しよう としたときにうまく動かない
ことがよくあります。
一般的なインフラ構築の場合、環境構築手順を作成してインストールや
セットアップを行います。
16
しかし台数が多くなると、人間が手作業で行うのは限界 があります。
そこで、インフラ構築するときは手順書をもとに構築するのではなく、
「コードに書かれたとおりの内容を自動で設定する」 しくみを導入すれば、
だれがそのプログラムを実行しても「同じ状態」のインフラ環境が構築できます。
17
18
また、本番運用中に構成変更があったときに、サーバの状態をきちんと
管理しておかないと、インフラ全体がブラックボックス化 してしまい、
たちまち手に負えなくなります。
コードで管理してさえいれば、アプリケーション開発におけるソースコードの
管理とおなじように、Gitなどのバージョン管理ソフトで履歴を管理することが
可能になります。
19
20
補足： Git
Gitとは、オープンソースの分散バージョン管理システムの一つ。 複数の開発者が
共同で一つのソフトウェアを開発する際などに、ソースコードやドキュメントなどの
編集履歴を管理するのによく用いられます。
バージョン管理システムの基本的な機能として、個々のファイルにいつ誰が
どのような変更を行ったかを記録しており、必要に応じて特定の日時の版を
参照したり、その状態に戻したりすることができる。
21
また、プロジェクトの時系列を分岐（ブランチ）して派生プロジェクトを作成したり、
それを再び元の系列に融合（マージ）したりすることができる。
Gitの特徴として、管理するデータの集合体であるリポジトリを利用者の手元の
コンピュータに丸ごとコピーし、必要に応じて中央の管理サーバと同期する
方式を取っている。
22
これにより、常にサーバと通信可能でなくても編集が可能で、検索や参照なども
高速に行なうことができる。
GitHubのようにインターネット上のサーバにGitの中央リポジトリを作成・運用できる
サービスもあり、GitHubに作成したリポジトリに各開発者がGitでアクセスして開発を
進めるというスタイルが オープンソースソフトウェアなどで人気となっています。
23
ここで、コードによるインフラ構築が広く行われている背景について
整理しておきます。
従来のオンプレミス環境におけるインフラ構築は、ハードウエアを自社で調達し、
その保守期限が切れるまで使うため、一度構築したものを、手入れしながら
長く使うというのが一般的なやりかたでした。
24
そのため、OS／ミドルウエアのバージョンアップだけでなく、本番運用時の
トラフィックに合わせて パフォーマンスチューニングなどを行い、さまざまな
インフラ構成要素を変更しながら運用管理をしていました。
そのため、インフラの構成管理の負荷が増大してきました。
つまり、「常に変化するインフラ」でした。
25
しかしながら、クラウドシステムの登場で、インフラ構築の手法が大きく
変わってきました。
クラウドは仮想環境をもとにしていますので、インフラ構築から物理的な制約が
なくなります。
そのため、これまでのオンプレミスでは難しかった、サーバやネットワークを
簡単に構築したり、一旦構築したものをすぐに破棄したり出来るようになりました。
26
そのため、一度構築したインフラは変更を加えることなく破棄して、新しいものを
構築してしまえばよく、これまで負荷の大きかったインフラの変更履歴を
管理する必要がなくなりました。
このようなインフラは「Immutable Infrastructure（不変のインフラ）」と
呼ばれています。
そして、インフラの変更履歴を管理するのではなく、動作している「インフラの状態」を
管理する必要性が出てきました。
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
補足： AWS CodeCommit
Git リポジトリをホストする、安全で高度にスケーラブルなマネージド型の
ソース管理サービスです。
AWS CodeCommit によって、インフラストラクチャのスケーリングに関する不安
要素は排除され、ユーザーが独自のソース管理システムを稼働させる必要が
なくなります。
44
AWS CodeCommit を使用して コードからバイナリまであらゆるものを
保存できます。
また、CodeCommitは既存の Git ツールと シームレスに連動します。
45
46
47
48
49
50
51
52
53
54
55
補足： 継続的インテグレーション
【 CI 】 Continuous Integration
継続的インテグレーションとは、ソフトウェア開発において、ビルドやテストを
頻繁に繰り返し行なうことにより問題を早期に発見し、開発の効率化・省力化や
納期の短縮を図る手法。
特に、専用のツールを用いてこのプロセスを自動化あるいは半自動化 し、
効率的に実施する方式。
56
ソースコードの追加や更新が行われる毎に、あるいは1日1回など定期的に、
プロジェクト全体のビルド や各モジュールの単体テスト、変更のあった
モジュール間の結合テストなどを実施する。
短いサイクルで頻繁にこれらを実施することで、問題点を早期に発見・修正でき、
不具合の原因究明も容易になる。
57
手作業でこうしたプロセスを実施することはコストが嵩むため、通常は継続的
インテグレーション支援ツール（CIツール、CI支援ツール）と呼ばれる自動化
ソフトウェアを用いて実施します。
58
59
60
61
62
補足： AWS CodePipeline
AWS CodePipelineは、ソフトウェアのリリースに必要なステップをモデル化、
視覚化、自動化できる継続的デリバリーサービスです。
AWS CodePipeline を使用して、コードを構築し、稼働前の環境にデプロイし、
アプリケーションをテストし、実稼働環境にリリースするまでの完全な
リリースプロセスを モデル化できます。
63
これにより、AWS CodePipelineは、コードが変更されるたびに定義される
ワークフローに従って、アプリケーションを構築、テスト、デプロイします。
リリースプロセスの任意のステージにパートナーツールまたは独自のカスタム
ツールを統合して、エンドツーエンドの継続的デリバリーソリューションを
構築することもできます。
64
AWS CodePipeline を使用する事により、構築、テスト、リリースプロセスを
自動化することで、AWS CodePipelineは、新しい変更を一貫した一連の
品質チェックを通して実行できるため、ソフトウェアアップデートの速度と
品質を向上できます。
65
66
67
補足： スモークテスト 【 smoke testing 】
スモークテストとは、開発途上のソフトウェアをテスト（試験）する手法の
一つで、開発・修正したソフトウェアを実行可能な状態に組み立て、
起動するかどうかや基本的な機能が動作するかなどをざっと確認すること。
本格的なテストを実施する前に行われる簡易なテストで、プログラムの追加や
修正などによって起動しなくなったり、すぐにエラーで停止してしまったりしないか
どうかを確かめるために行われる。
68
テストの進行を妨げる致命的なバグを早期に見つけ、効率的にテストを
実施するために必要となる。
もとは電子機器・電気機械の開発工程において、試作品の電源を投入してみて
発煙しないか調べる試験を意味する。
回路の短絡など 致命的なミスがないか 調べるために行われる。
69
70
71
ブルーグリーンデプロイメント (Blue-Green Deployment)
これまで使ってきたサーバーを、新しいサーバーに更新する際に使われる手法の
ひとつ。
従来のサーバーは、構築したあともソフトウェアの更新や設定変更を繰り返して
使って行くのが一般的だった。
72
特に、物理的なサーバー（コンピュータ）を用意して運用している場合、
新しいサーバーに切り替えるのは容易ではなかったです。
また、サーバー更新の際は事前にテスト運用するものの、実際に稼働してから
トラブルが発生するリスクが伴います。
最近は、クラウドサービスを利用して比較的簡単に仮想サーバーを構築できる
ようになっています。
73
そこで、現在稼働しているサーバーとは別に新たなサーバーを構築し、準備が
できたら スパッと切り替える。
もしも新しいサーバーに問題があったら、即座に古いサーバーに戻すという
手法が提唱されました。 この方式を、ブルーグリーンデプロイメントといいます。
74
デプロイメントは、「配置する」とか「展開する」といった意味で、ITの世界では
「新しいソフトウェアやシステムを利用可能な状態にする」ことを指します。
ブルーとグリーンは新旧サーバーの仮称です。
たとえば、従来のサーバーを「ブルー」と呼んで、新しいサーバーを「グリーン」
と呼ぶとしよう。
そして、グリーンの準備ができたら、ブルーからグリーンに切り替える。
75
もしグリーンに不具合があったら、ブルーに戻してグリーンを修正し、また
ブルーからグリーンにつなぎ直せばいい。
これによって、サーバー更新に伴うシステム停止時間を大幅に短縮できる。
また、運用開始直後のトラブルのリスクも軽減できる。
76
77
78
79
補足： Capistrano
Capistranoは、複数のサーバー上で スクリプトを実行するための
オープンソースのツールであり、その主な用途は、ウェブアプリケーションの
ソフトウェアCapistranoはRuby言語で書かれており、RubyGemsに
よって配布されています。
80
81
82
補足： Fabric
Fabric はPython 製のデプロイ・システム管理ツールです。
Fabric の最大の特長は、シェルスクリプトを書き慣れた人がいきなり
利用できるところです。
シェルスクリプトとしてまとめていたコマンドをそのまま run() メソッドや
sudo() メソッドで囲むだけで、使うことができます。
83
シェルスクリプト を使っていていると、いくつもの問題に遭遇します。
・名前空間の管理
・変数の扱い
・複雑なデータ構造がない(せいぜい配列ぐらい)
・例外処理
Fabric は Python で記述しますので、上記の問題は全て解決します。
84
85
AWS CodeDeploy
AWS CodeDeploy は、Amazon EC2 インスタンス、およびオンプレミスで
稼働するインスタンスを含む、さまざまなインスタンスへのコードのデプロイを
自動化するサービスです。
AWS CodeDeploy を使用すると、ユーザーはアプリケーションの複雑な
アップデート処理、デプロイ中のダウンタイムの回避、新規機能の迅速な
リリースが容易になります。
86
AWS CodeDeploy を使用すると、エラーを起こしやすい手動操作や
インフラストラクチャのサービススケールの必要性を排除しながら、
デプロイの自動化を行うことが可能となり、 1 つのインスタンスへの
デプロイや、数千のインスタンスへのデプロイも容易に行うことができます。
87
88
89
AWS Elastic Beanstalk
AWS Elastic Beanstalk は、AWS クラウド内でのアプリケーションの
デプロイと管理を さらに簡単にするサービスです。
開発者は単にそのアプリケーションをアップロードするだけで、
Elastic Beanstalk が自動的に容量のプロビジョニング、負荷分散、
Auto-Scaling、およびアプリケーション状態モニタリングといった デプロイの
詳細を処理します。
90
クラウドコンピューティングの経験がなくても開始できます。
WS Elastic Beanstalk では Java、.NET、PHP、Node.js、Python、
Ruby、Go、Dockerのウェブアプリケーションがサポートされます。
91
92
93
94
95
補足： Docker
Docker とは、Linux上で独立した別のLinuxシステムを起動することができる
コンテナ型の仮想化ソフトウェア の一つ。
Docker社（旧dotCloud社）が 開発を創始したもので、オープンソースとして
公開されている。
96
コンテナ型の仮想化では仮想的な物理マシンの構築は行わず、元のOS環境上に
隔離されたエリアを作り、仮想的に新たなOS実行環境を作り出す。
Dockerは LXC（Linux Containers）により Linux上に隔離された環境を作り出し、
元の環境に影響を及ぼさずに アプリケーションソフトの実行ができる。
97
OSの設定やアプリケーションソフトの導入の済んだLinux環境を丸ごと実行
イメージとして保存する機能があり、別のマシンのDockerに持ち込んで
そのまま実行することができる。
これをソフトウェアの配布に応用すれば、 複雑な導入・設定作業を省略し、
元の環境との違いなどを意識しなくても 簡単にソフトウェアを導入できる
ようになる。
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
参考文献：
Amazon.com, Inc.社 公開資料
123
本資料の関連資料は下記をクリックして
ＰＤＦ一覧からお入り下さい。
ＩＴライブラリー （pdf １００冊）http://itlib1.sakura.ne.jp/
目次番号 ４５３番 ＡＷＳ詳細解説 全３３冊 計６,１００ページ
124
Recommended