AWS学習 2日目
お疲れ様です。
3日くらい開いてしまい、早速毎日やるというところが崩れつつありますが、時間はありますのでのんびり進めていきます。
前回はクラウドとオンプレミスの違いと、AWSを利用するメリットについて学習しました。今回は実際にシステムを構築するにあたって、どのような設計原理を用いているのか、多少日にちが空いてしまっていますがアウトプットしていきます。
前回同様、もし識者の方がこの記事を読んでいましたら、解釈の違い等あればご指摘いただけると幸いです。
まず、システムを構成するうえで重要になるのが、何かしら不具合があった際の対応です。オンプレミスでもクラウドでも、機材やソフトの故障や、災害によるトラブルは人が作ったものである以上つきものです。
ではどうやってそれらと向き合っていくのか。そのためには根本的な部分から考え直す必要があります。『トラブルがあってから対応』するのではなく、『予め起こりうるトラブルを想定』するのです。トラブルが発生した際、それに対処・処理をするメカニズムを予め組み込んでおくのです。
これをDesign for Failure、故障に備えた設計と言います。そのままですね。実に単純です。Design for Failureを採り入れた設計をすることで、耐故障性の高いアーキテクチャ*1を構築することができます。
実現するためには、まず単一障害点という、障害の起こりうるポイント1つ1つに予め対処することが必要になります。
耐故障性の高い設計をするための理想をこれまで述べてきましたが、では実際にクラウドではどのような手法が用いられているのでしょうか。
基本的にクラウドではサービス指向アーキテクチャの設計原則を踏襲しています。サービス指向アーキテクチャとは、個別のコンポーネント*2の集合体で1つのシステムを構成することを言います。つまり、それぞれ独立した要素１つ１つの集合体で１つのシステムを形作っていくようなイメージで、たとえ1つのコンポーネントが何らかの理由で停止してしまった際に、他のコンポーネントでそれを補う事で、まるで何もなかったかのように作業を継続することが可能となります。
そしてそれを実現するためには、コンポーネント1つ1つの疎結合が重要になります。疎結合とは、システム上のアプリケーションを構成するレイヤーやコンポーネント1つ1つを隔離し、依存しあわない形で構築することを言います。例えばWebアプリケーションの場合、Webサーバやアプリケーションサーバ、データベースといった形でそれぞれが直接的な関わりを持たない形で構成成分を隔離することができます。
ですが、隔離されていて機能的な依存性はないとは言いつつも、お互いがお互いに相互作用するような関係性は形成されています。1つ1つが他方のブラックボックス*3として存在している状態になるのです。なので、1つが停止してしまっても、ある程度の機能は補うことが可能になります。
またこういった形で分離化を実現するには、Amazon SQS（Single Queue Service)を使ったキューイングチェーンを利用します。それぞれのキューは処理が完了するまでデータが残っているので、仮に処理中のリソースに障害が発生してもチェーン内にある他のリソースを使用することで処理の継続が可能となります。利用することで、それぞれが同期や依存はしていないものの、お互いがお互いを補うことのできる、疎結合のコンポーネントを構成することが可能なのです。
今回はここまでです。要するにシステムを設計するときには、大黒柱1本で支えようとするのではなく、短い間隔で柱を大量に用意した方が安全だよね、安心だよね、という理屈というわけですね（解釈違いかもしれませんが）。
色々初めて触れる単語や考え方が多かったので、テキストの内容をほぼ書き写したような内容にはなってしまっていますが、元々テキストが学習の要点をまとめたものですので、むしろそのまま理解する方が結果的には良いのではと思います。
明日からはまた毎日更新に頑張って戻したいと思いますので、もし読んで頂いている方がいらっしゃいましたら、応援の程よろしくお願いいたします。
まだまだインフラエンジニアとしての道のりが長いように感じますが、1歩ずつ確実に踏み出していきたいですね。
ではまた明日。
