AWS は Amazon Web Services の事で、Amazonが提供するクラウドコンピューティングサービス群の事ですが、今web系サービスを始めとして、サービスの基盤・サーバ環境に、このクラウドコンピューティングサービスを使う企業が増えてきています。
クラウドコンピューティングの代表として、
- Amazon の AWS(Amazon Web Services)
- Google の GCP (Google Cloud Platform)
- Microsoft の Azure
がありますが、今回はAWSについて触れます。
見出し
今までのレガシー環境で抱える問題
今までの環境で抱える問題があるからこそ、AWS等のクラウドコンピューティングサービスの需要が高まってきたわけです。先ずはその問題についてご説明します。
今までの古い環境を指す意味で良く使われるのがレガシー環境です。今回もこれを使います。
では、レガシー環境での様々な問題について見てみましょう。
オンプレ環境での問題
レガシー環境の中にオンプレ環境があります。オンプレ環境とは自社やデータセンターに物理的にサーバを設置した環境の事です。2000年頃のドットコムバブル・ITバブルで一気に今でいう老舗webサービスが登場し、その時代ではオンプレ環境は割と一般的でした。
オンプレ環境だと、売上が出る前から物理的なサーバを用意するわけなので、コスト的にも最初に大きな投資をしなければならなく、リスクが高まります。
また、夜間トラブルの対応や停電の対応や故障の対応もしなければなりません。 サービスを切断なく運用する為には、最低限2台が必要となります。更に、サービスが伸びていった時にサーバ増設していったりスペックを上げていく必要が出てきます。
常に何かの移行計画を走らせるような状況にもなる為、インフラチームが必要になってきます。
独自仕様に合わせた環境が構築出来たり、長期運用が実現出来れば結果的に安く済むというメリットもあります。
バージョンアップ問題
サーバOS、ミドルウェア、言語等のバージョンアップをしなければいけません。バージョンアップを適切にしていかないと、セキュリティリスクが高まります。また、各レイヤー毎の依存関係がある為、DBのミドルウェアだけ最新バージョンにするとか、プログラム言語だけ最新バージョンにするといったような、1レイヤーだけ最新の事が出来なくなります。
これを例えるならば、フラフープの中にある複数の石像です。この石像たちを1m先の場所に押して動かしたいです。ただし、フラフープを外す事は出来ない制約があります。1つを一気に1m先に動かす事は出来ないので、フラフープの範囲の中で1個ずつずらしていく必要があります。もしくは、ブルドーザーなどで一気に石像たちを同時に押すかです。でもブルドーザーは高価ですしスキルも必要で危険も伴います。
モノリシック問題
モノリシックとは一枚岩という意味です。似たような用途でスパゲッティコードという言葉も使われますが、どちらも、修正をしたくても紐づくものが多すぎて手を付けられ難い状態を指します。その粒度はアーキテクチャとしてだったり、コードとしてだったりしますが。
仕様変更が途中で入る事は普通にあり、これまで長期運用されたサービスであれば、つい売上重視のその場しのぎの箇所が出てきてしまいます。それがベースとなって上にどんどん仕様変更が重なってくると、後になって修正するにはその箇所全体を丸っと直さないといけなくなってくる事は多々あります。
ただ、これは戦略なので先か後に払うかの話で経営方針次第です。大切なのは、スピード重視にした際に、こういった問題を抱えていく事になるという認識があるかないかだと思います。あとで支払う事になる為、「負債」と呼ばれます。
セキュリティ的な問題
サーバを公開するとOSや言語などのセキュリティホールが見つかった際に、自分で情報をキャッチアップして試してリリース・移行する必要があります。
インフラチームがいれば心強いですが、少人数でのチームの場合、インフラに強いメンバーがいない事も多いです。有事の際に対応出来るのか、情報の取捨選択だけでもインフラの知識がないと難しいケースもあります。
レガシー環境での問題点まとめ
上記までで、いくつか問題に触れました。これまでのレガシー環境であったこれらの問題をAWSを始めとするクラウドネイティブ技術で解決したい為、需要が出てきています。
- オンプレ環境での問題
- バージョンアップ問題
- モノリシック問題
- セキュリティ的な問題
AWSにする事によるメリットとは？
では、AWSにする事によるメリットを見ていきましょう。
オンプレに対するクラウド
自動拡張（オートスケーリング）
例えば、サービスに大量アクセスが来た時に、webサーバであればサーバ台数を増やせば落ちないように・レスポンスも遅くならないように出来るとします。それを手動（自前プログラム）でやるには作るのも大変ですし、ノウハウも必要になってきます。これをやってくれるのがAWSのマネージド型サービスやオートスケーリング機能というわけです。負荷がかかれば勝手にサーバを増やしてくれたりします。 マネージド型サービスであれば、内部のサーバがいくつかなど気にする必要もなく、これがサーバレスと呼ばれる所以でもあります。
節約
レガシー環境時代には、大量アクセスを予期して予めサーバをスタンバイさせておく必要がありました。そうすると、普段は使わないのにチェックする時間・仕組みやサーバ代が余計にかかったりしました。これが必要になった時だけ自動拡張する事によって普段は余分なコストが発生しなくなりました。 コンテナ技術も進んできており、サーバを立ち上げるというよりコンテナが立ち上がるという形になってきて更にスムーズな切り替えが出来るようになってきました。
また、クラウド化すると、自前でサーバ機を買ってきて会社に置いて、インストールしたり、冷却の電気代を払ったり、土地的なコストがかかったり、というコストから解放されます。もちろんAWSに対してのコストはかかりますが、直近の人件費を考えるとクラウド化した方が良くなる為、メリットがあるレベルの値段になっています。
バージョン管理
セキュリティ的にバージョンアップする必要が出てきたりする事があると思います。いざ実施するとなると、手順・開発など色々なコストがかかってきてしまいます。これを自分でやらずにAWSに任せられるのであれば、本来やりたかった利益を追う作業に集中出来ます。
専門的な技術を必要としない
web画面からポチポチウィザードに従って設定していくだけでインフラが構築出来るので、アプリ側の開発に専念出来ます。
ただ、これはまだまだ完全にそうではないです。専門的な知識がないとこのポチポチが出来ない箇所もあったり、構成を考えられなかったり、AWSが記載している説明の意味が理解出来なかったりしますので、現状では専門的な知識の少なくとも概要・用語くらいは最低限知っていないとAWSのメリットを最大限活かす事は出来ません。
マイクロサービス化でバージョンアップ問題とモノリシック問題を解消
マイクロサービスとは、モノリシック（一枚岩）との反対で、細かく機能毎などに分離されている状態を指します。AWSにはニッチなサービスがいくつもありますので、これらを組み合わせて使う事で、モノリシックで手を入れられないという状態を解消出来ます。疎結合で分離されているので、修正箇所だけいじれるというイメージです。マイクロサービス化する事により、今後この小サービスだけを別サービスに入れ替えたりする事も可能になるので、拡張性もあがります。
バージョンアップについてもマイクロサービス化で分離されていれば、該当の箇所だけをバージョンアップする事が出来ます。
インフラのセキュリティはプロに任せる
アプリケーション側のセキュリティは開発チームが担保する必要がありますが、インフラ側はAWSのマネージド型サービスであれば、サーバは向こうにあり、こちらで対応する必要もありません。
まとめ
レガシー環境での問題点とAWSを使用してその問題をどのように解消していくのか、ふんわりと触れました。
各サービス毎のまとめ記事も書いていきますのでご覧ください。