AWSを学ぶ前に知っておきたいことを人気AWS本著者に解説いただく本連載。今回のお題はクラウドネイティブの前提となる「作っては捨てる」発想について。せっかく作ったサーバーを捨ててしまうとは、いったいどういうことなのでしょうか？
＊連載「ゆるく学ぶサーバー入門～イマイチわかりづらいサーバーの基礎を解説～」も併せて読むと、より理解を深めることができます。ぜひご覧ください。
今回のサマリ
- 管理が楽になるマネージドサービス
- マネージドサービスの前提「作っては捨てる」
- オールインワンで揃えられるけれど、選ぶ必要あり
- 「もうEC2は使ってないよ」とは、どんな現場なのか
- クラウドネイティブという考え方
AWSなどのレンタルのクラウドプラットフォーム（パブリッククラウド）を「プロジェクトに取り入れよう！」と思った時にオンプレミスで構築していたサーバーをそのまま持ってくるようなイメージでやってしまうと、AWSの良さはあまり活かせません。
なんとなく、世間では、「進化したサーバー」「オンプレはもう古い」「従来のレンタルサーバーの上位互換」のようなイメージで語られることもありますが、そういうものではありません。オンプレミスでの構築や、従来のレンタルサーバーとは特徴が違うだけです。良いところもあれば、そうでないところもあります。どちらが優れているという性質のものではありません。ですから、その特徴をちゃんと活かさないと、「ただの高いサーバー」になってしまうのです。
今回はAWSを使う上でのポイントをいくつかご紹介しましょう。
管理が楽になるマネージドサービス
パブリッククラウドの多くが備えている性質として、まず一つ目に上げられるのは、マネージドサービスです。
AWSやGoogle Cloud、Microsoft Azureでは、「マネージドサービス」と呼ばれる業者側が管理するサービスと、「アンマネージドサービス」と呼ばれる管理しないサービスがあります。
AWSの代名詞であるAmazon EC2（サーバーが借りられるサービス）はアンマネージドサービスですが、Amazon S3（ストレージを借りられるサービス）、Amazon RDS（データベースを借りられるサービス）などは代表的なマネージドサービスです。
マネージドサービスでは、バックアップやアップデートが自動で行われます。また、サービスや、設定によっては、スケールアウト（サーバーやストレージの性能を上げること）や、スケールアップ（サーバーやストレージの台数を増やすこと）を自動で行います。
こうした自動管理が設定されていると、突発的に容量の増減が必要な事態が発生した時や、急いでソフトウェアのアップデートをしなければならないときに大変便利です。管理者の手間が大きく削減されます。
一方で、自動で行われるということは、アップデートしたくないのにソフトウェアがアップデートされてしまったり、想定以上にストレージ容量が増えて料金がかさんでしまったりすることもあります。 特に、ソフトウェアのアップデートに関しては、特定のソフトウェアのバージョンでなければ動かないシステムやアプリケーションもあるので、アップデートしたはいいものの、突然止まってしまったということもありうるわけです。
それでも、サーバーの管理というものは、手間も時間もかかるものなので、作業をしなくてよいのは、大きく負担が減ります。
（出典）『図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書』 p.30より
マネージドサービスの前提「作っては捨てる」
このマネージドサービスを利用するには、「作っては捨てる」仕組みをよく理解しておくことが肝要です。
例えば、ソフトウェアのアップデートを行いたい場合に、今までは普通にアップデートをしていたと思います。Linuxサーバーに少し詳しい人であればaptやyumコマンドをサーバーの管理者が手動で入力して、アップデートやアップグレードをしていたと言うと通じるでしょう。一つのサーバーがあれば、それに対してメンテナンスを繰り返し、使っていくという考え方です。
しかし、パブリッククラウドではこのようなアップデートはせずに、古いサーバーは捨ててしまって、新しいサーバーを立てなおした方が色々とスムーズです。まさに「作っては捨てる」のです。
何かのソフトウェアの「ver7」を「ver8」にしたい場合は、すでにあるver7をアップデートするのではなく、ver7を捨てて、ver8をインストールします。
（出典）同人誌「明後日から使えるAWS入門」より
このように話すと、従来のサーバー管理を知っている人からすると、面倒くさいと思うでしょう。
たしかに、従来の方法で新しくインストールしなおすのであれば、時間も手間もかかります。しかし、クラウドの場合は、そう面倒なことではないのです。この連載の第一回でも話したとおり、パブリッククラウドでは、ソフトウェアのインストールを、ボタン一つで行うことができます。
つまり、ボタン一つで新しいものに変更できてしまうのです。簡単です。そして、そもそもマネージドサービスであれば、問答無用で、自動的にそれを行うサービスもあります。
また、このようなライフサイクルにするために、「作っては捨てられるように」しておくことも肝要です。古いソフトウェアを捨てる時に、ソフトウェアの設定ファイルなどを一緒に捨ててしまっては、また1から設定しなおしです。
ですから、設定ファイルは、別の場所に保存しておいたり、コピーして戻せるようにしておく必要があるでしょう。もちろん、データベースなど、「消滅してはならないデータ類」も同じです。入れ替え予定の場所ではないところに、保存されるように設計します。
そもそも、最近のサーバー管理では、設定ファイルを直接変更することは減っており、別途、自分がカスタムしたファイルを作成して、それを起動時に読み込ませる傾向になっています。データベースも、別に管理されることが多いでしょう。そのような意味でも、すでに「作っては捨てる」方向に、業界全体が進んでいるのです。
オールインワンで揃えられるけれど、選ぶ必要はあり
パブリッククラウドの二つ目の特徴としては、「オールインワンで揃えられる」点があげられます。
これはパブリッククラウドのベンダーにもよるのですが、大手ベンダーでは、サービスの種類が豊富です。例えば物理的なマシンとソフトウェアとドメインやネットワークなどをバラバラに調達するのではなく全て一つのクラウドサービスから調達することができます。
実際に、自分で簡単なサーバーを立ててみるとわかりやすいのですが＊、大層なサーバーでなくとも、意外と用意するものは多く、それを一つのベンダーで用意できるのはありがたいことです。
ただ、「あまりよく考えずに、全部を一つのパブリッククラウドで揃える」ことは良いことではありません。ベンダーによって得意不得意もありますし、そもそもパブリッククラウドが苦手なものもあります。
よく言われるのは、ゲームや動画配信です。自動でスケール（サーバーの機能や台数を変更すること）を必要とせず、大規模なストレージを必要とするようなプロジェクトを、すべてパブリッククラウドで実現しようとすると費用がかさみがちです。
ですから、一部をオンプレミスで用意して、一部をパブリッククラウドのように、組み合わせて使ったりもします。スケールして欲しいところはパブリッククラウドを使って、そうでないところは、自社で用意するのです。
また、ベンダーによって、得意不得意もあるので、「得意なものだけを組み合わせる」使い方もよくされます。「この部分はAWS、ここから先はGoogle Cloud」のような使い方です。
ただこれには一つ落とし穴があって、オンプレミスや、他のサービスと組み合わせる場合に、少し高くなってしまうこともあります。
まとめると、「何をどのパブリッククラウド」を使うのか、全体の費用を考えつつ、構築するのがポイントです。どんなものでも、よく知らないまま、雰囲気で使うと火傷（やけど）します。特徴を良く知り、自分にとってどのように有益か考えながら、使っていきましょう。
（出典）『図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書』 p.35より
＊もし、自分でサーバーを立ててみたくなったら、秋葉原などで安い中古のWindowsのノートパソコンを買ってきて、OSやソフトウェアを入れてみましょう。実際に外部と通信できるWebサーバーを自分で立てるのは、現在の状況では難しいですが、家や会社で使う程度のサーバーでも自分で触ってみれば、十分勉強になります。
「もうEC2は使ってないよ」とは、どんな現場なのか
こうした特徴があるため、AWSで最も有名な Amazon EC 2（サーバーを借りられるサービス）も、最近では使わないプロジェクトが増えています。
まったく使わないというわけではないのですが、最初に書いた通り、EC2はアンマネージドサービスなので、AWSが自動で色々と管理してくれないのです。
従来のサーバー管理者からすれば、当たり前のことですし、その方が良いと考えるむきもあるでしょう。しかし、パブリッククラウドのメリットの一つはマネージドであることなので、それを使わないのであれば、魅力が半減してしまうのです。
ですから、できるだけマネージドサービスを使って、サーバー管理・運用の手間を削減したいと考えるような現場では、EC2はあまり使われなくなっています。代わりに、AWS FargateとAmazon ECS（どちらもコンテナに関わるサービス）を組み合わせて、構成にコンテナ＊を取り入れたり、AWS Lambdaでサーバーレスを取り入れたり、Amazon RDS（データベース）を利用したりしています。
＊コンテナは、プログラムを隔離して実行できる仕組み。Doker社のDockerが有名
クラウドネイティブという考え方
こうした、クラウドを使う前提で設計することを「クラウドネイティブ」と言います。
クラウドでは、「作っては捨てる」を前提にしなければ、マネージドサービスは使いづらいですし、そのためには、「作っては捨てられる」ように設計しなければなりません。ですから、冒頭でお話ししたとおり、「なんとなく、オンプレミスのリプレースで」という感覚でやると失敗してしまうのです。
パブリッククラウドを活かしたいなら、それ相応の、考え方や、設計方法を身につける必要があります。
このように話してしまうと、現在のプロジェクトが、クラウドを使うに適した状態と異なっている場合、不安に思うかもしれません。自分には早いかな？と思うのも、また一つの考え方でしょう。
ただ、クラウドにはこれ以外にも有益な特徴があります。やはり、ワンクリックで色々なことができるのは便利ですし、従量制なので、イニシャルのコストは低いです。「活かしている」とは言えなくとも、メリットがあるなら使えば良いのです。
今回お話しした内容は、いわばパブリッククラウドを使うにあたり、目指すべき方向です。
ですから、現時点で関わっているプロジェクトが、クラウドを使うに適していないからと言って、及び腰になるのではなく、簡単なところから取り入れていき、少しずつパブリッククラウドとの付き合い方がどのようなものになるのかを考えていくと良いでしょう。
「作っては捨てる時代がやってきた」
AWSなどの大手パブリッククラウドでは、「マネージドサービス」や、「オールインワン」で揃えられることが大きなメリットです。特に、マネージドサービスを巧く利用するには、「作っては捨てる」考え方を設計に入れる必要があります。
ただ、これ以外にもメリットはありますし、最初から大きなことをやろうとすると失敗しがちなので、簡単なところから取り入れていくと良いでしょう。
▼これまでの「AWS文明開化〜イマイチ掴めないクラウドの正体とメリットを解説〜」
・AWSってなんでこんなにチヤホヤされてるの？
