プログラミング初学者がまとめる〜RDSについてまとめてみようと思う。ざっと理解する編〜
今回は、アプリケーションデプロイ時に欠かせないDBについての記事です。AWSにも、低コストかつ高パフォーマンスなリレーショナルデータベース（RDB）を構築できる、Amazon RDSというサービスがあります。(RDBについての説明は省略)
◯RDSとは
RDSとは(Relational Database service)の略で、AWSがクラウド上で提供するRDBMSサービスです。RDSでは、データベースのインストールやバックアップなどのセットアップをしなくても、データベースが利用できる環境が提供されているため、契約後すぐにAWS上でデータベースを使用することができます。
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
◯RDBMSとは
コンピューター上でRDBを構築するには、通常「RDBMS（Relational DataBase Management System）」と呼ばれるリレーショナル型データベースを管理するためのソフトウェアを使用します。つまり、データベースを構築したり更新したりする際に使用するためには、RDBMSが必要であるということです。RDBMSの代表的なサービスとしては、OracleやMySQLが挙げられます。
RDSでは以下の6つのDBを利用することができます。無料と書かれているものはオープンソースとなっているため無料みたいです。
・Postgre SQL (無料)
・MySQL (無料)
・Mariaデータベース (無料)
◯メリット（オンプレと比べて）
オンプレミスサーバーと比較して物理的な運用が容易
Amazon RDSの場合はそもそも物理的なサーバーを必要とせず、クラウド上で容量を追加するだけでよいので、物理的な運用が容易です。
スケーラビリティが高い
データベースの容量の増減を簡単なマウス操作のみで処理することができます。必要量に応じた料金のみの支払いで、急なデータ容量の追加にも対応することができます。
ソフトウェアの自動パッチ作業
パッチ作業とはプログラムの機能追加や修復などのバージョンアップ作業のことです。RDSでは、バックアップの実行やデータベースを強化するソフトウェアのパッチ適用などの作業が自動化されます。オンプレミスの場合には、パッチ作業の管理を自身で管理しなければならないため、手間が大きく軽減されます。
自動バックアップ
Amazon RDSでは、非常に手間のかかるバックアップ作業についてもAWS側で自動的に実行させることが可能です。業務の負担や手間を軽減し、バックアップのし忘れを防いでくれる効果もあります。
Multi-AZによる可用性
Multi-AZオプションをONにすると自動的に2つのAmazon RDSを異なるAZに構築してくれます。
2つのAmazon RDSを構築することにより、片方のAmazon RDSにトラブルが生じた場合でも、影響を受けずにAmazon RDSにアクセスすることができます。
◯まとめ
今回はRDSのアウトラインについてまとめてみました。
環境設定や管理を勝手にやってくれるのが便利ですね！！
最後まで読んで頂き、ありがとうございました！！
プログラミング初学者がまとめる〜CloudFormationについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回はクラウドフォーメーションについてまとめて思います。
ECSでクラスターを作成している時に勝手に作られていてこれ何？って思っていたのでざっくりまとめてみます。
◯CloudFormationとは
CloudFormationはAWSの管理ソフトの一つと言えるでしょう。
具体的には、AWSのシステム構成をJSONで記述してテンプレート化し、構成の管理、修正、再利用を容易にするサービスです。
AWS CloudFormation を利用すると、AWSで環境構築するときに、リソースの設定やプロビジョニングをコード化したテンプレートを作成できます。それをもとにすれば、次に新しい環境を構築するとき、時間や手間を大きく削減できるのです。
リソースとは、AWSで提供されているEC2やVPCなどのサービス、それらをつなぐAttacheといった、環境を構築するパーツのことです。
◯メリット
インフラの管理や制御が簡単になる
CloudFormationは、テンプレートからスタックを作成してモデル化することで、その環境で利用するすべてのリソースを一括して管理したり、運用したりすることが可能になります。CloudFormationを使わない場合、開発者がそれぞれのリソースを個別に管理し、設定しなければなりません。それでは環境の構築に大きな時間や手間がかかりますし、人為的なミスも発生してしまいます。
AWS CloudFormationを利用すれば、開発時間や作業が増えたり、ミスが増えたりすることも抑えられます。
◯インフラをテキストファイルでモデル化できる
シンプルにかっこいいですよね！！笑
CloudFormationのテンプレートは、テキストファイルで作成します。つまり、CloudFormationを使えば、たくさんのインフラをテキストファイルでモデル化したうえで管理することが可能です。それによって、インフラを容易に取り扱うことができます。
◯料金は無料
CloudFormationの利用料金は無料です。ただし、AWS CloudFormationは単独で利用することはありません。Amazon EC2やAWS ELBなど、ほかのAWSリソースと併用します。そのため、利用しているほかのAWSリソースの料金が必要です
◯まとめ
今回はCloudFormationについてまとめてみました。
自動で作られていたものは、とても素晴らしい管理ソフトでした！！笑
今度はコードでCloudFormationを書いてみようと思います。
最後まで読んで頂き、ありがとうございました！！
プログラミング初学者がまとめる〜ロードバランサーについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回はELBについて書いていこうと思います。前回のVPCの話と関連づけて理解するとベターだと思うので関連付けながら勉強してもらえると幸いです。
◯ ELBとは
ロードバランサーとは、リクエストを複数のターゲットに分散し、安定稼働をするために使われるものです。関門みたいに配置し、ロードバランサーを通ってから、処理が行われるようになります。
AWS ELBはAWS Elastic Load Balancingの略で、AWSにあるロードバランサーのことを指します。またALB、CLB、NLB(後述)という3種類ロードバランサーの総称として使われることがあります。
◯機能・特徴
複数のサーバーへのトラフィックに分散する
AWS ELBで複数のサーバーにアクセスを分散させることで、アクセス集中によるサーバーダウンを防ぎます。それによって、処理速度の向上や、高い可用性の維持が期待できます。
サーバーのヘルスチェック
AWS ELBは、常にリクエストをトレースし、接続しているサーバーをモニタリングしています。それによって、リアルタイムにアプリケーションのヘルスチェックが可能です。異常な動作を検知した場合は、そのサーバーを切り離し、トラフィックをほかのサーバーに分散するので、アプリケーションの安定稼働が維持されます。(ヘルスチェックというのは、サーバーが生きているか確認してくれる機能のことです）
セキュリティ面
AWSのロードバランサーは、VPCの中に配置されているため、必要なトラフィックだけを通過させて、不必要なものや安全性に信頼が持てないものをシャットアウトする、と言うような事ができます。
高い可用性
AWSのロードバランサーを利用することによって、高い可用性を持ってWebサービスを運用・運営できるようになります。
◯ELBの種類3つ
・Application Load Balancer（ALB）
AWS ELBのうち、最新で最も高機能なロードバランサーです。基本的には、ALBを使用することが推奨されています。HTTPトラフィックおよびHTTPSトラフィックの負荷分散、柔軟なアプリケーション管理が必要な場合に向いているロードバランサーです。
・Network Load Balancer(NLB)
毎秒数百万のリクエスト処理が可能で、高度なパフォーマンスが必要な場合に使用します。突発的なトラフィックや急激に変化するトラフィックにも対応可能です。
・Classic Load Balancer（CLB）
複数のAmazon EC2インスタンスにおける基本的な負荷分散を行う、基本的なロードバランサーです。EC2 Classicネットワーク内で構築された既存のアプリケーションがある場合は、Classic Load Balancerを使用しなくてはなりません。
◯ELBの料金
AWS ELBの料金は従量制で、使用した分のみ支払います。最低料金や初期費用は不要で無料利用枠もありません。料金は、使用するロードバランサー、およびリージョンにより異なるので、注意が必要です。料金が発生するものは次の2つです。
・ロードバランサーを使用した時間（1時間単位）
・転送データ量（GB単位）
◯まとめ
今回はロードバランサーについてざっくりまとめてみました。
ざっくりとEC2のセキュリティー周りが理解できていたら幸いです。
最後まで読んで頂き、ありがとうございました！！
プログラミング初学者がまとめる〜AWSネットワーク周りについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回はAWSのネットワーク周りの言葉についてざっくりまとめてみました。
言葉の定義中心になります
私は図にして理解しました。図はたくさんあるのでググってみてください。。
◯VPCとは
Virtual Private Cloudの略です。
ネットワークを構成する一番大きな箱だとイメージしてもらいたいです。
専門的にいうと、AWS内の領域を表します。その領域内ででのIPアドレス管理や、インターネットとどう接続させるかなどの設定が必要になります。
◯サブネット
サブネットは、VPCの中をさらにサブネットという箱で分割するイメージです。
専門的にいうとVPCという大きなネットワークのくくりの中に、小さいネットワークの集まりを作ることができるコンポーネントであるとも言えます。またサブネットにはAZ（アベイラビリティゾーン）の設定が必要になります。
◯リージョン
AZの説明の前にまず、リージョンについて説明します
AWSにはリージョンと呼ばれるAWSの拠点があります。EC2とVPCを利用する前に、あらかじめどのリージョンにするか選択する必要があります。
北アメリカやヨーロッパ、東南アジアなど様々な地域に存在しており、地域ごとに利用料金が異なります。距離が遠いほど通信に時間がかかるため、サービスを提供する地域に合わせてリージョンを決定します。（日本だとap-northeast）
◯AZ（アベイラビリティゾーン）
AZはリージョンの中にあるデータセンター群を指し、「1つのリージョンは2つ以上のAZで構成され、それぞれ災害などの影響を受けにくい地理的に離れた場所にある」とされています。 そして、1つのVPCのなかに複数のAZがある状態になり、これを活用することで冗長構成が可能になります。
例えばAZ-Aの地域で地震が起きてAZ-Aのサーバーがダウンしたとします。
しかしあなたは全く同じ構成でAZ-Cにサービスのクローンを用意していました。
AZ-Cは地震の影響を受けていなかったので、AZ-Aをメインに利用していたサービスをAZ-Cヘ切り替えることで、安心してサービスを継続できるというわけです。
◯ルートテーブル(rt)
サブネットごとに「どこに接続できるか」を設定するものです。これをきちんと設定することで、システムからの通信経路を制御し、安全性を担保できます。
◯セキュリティグループ(sg)
セキュリティグループはインスタンス単位で設定できるファイアウォールです。つまり、どのインスタンスがどこと通信できるかを制御できるということになります。
ルートテーブルと機能がかぶる気がしますが、そこはもちろん違いがあります。VPC内にサブネットを複数構成した場合、ルートテーブルの設定ではサブネット間の通信は制御できず、サブネット同士の通信はすべて許可されてしまいます。でもサブネット間でも「こことここは通信NG」と制限したいケースもあるはず。この制御を実現するのがセキュリティグループです。サブネット単位ではなく、インスタンス単位に通信の許可/禁止を設定できるため、より細かな通信制御が可能になります。
◯インターネットGateway(igw)
VPC内からインターネットに接続するためのゲートウェイです。これがないと外部からアクセスすることができません。これを使うことで、VPC内のシステムがグローバルIPを使えるようになります。
◯まとめ
以上でAWS(EC2)のセキュリティ関連の言葉を抑えられたのかなと思います。
これらを全て結びつけれあげることで、インスタンスが安全に稼働・管理できるというわけです。
かなり言葉が多くて挫折しかけた私でしたが、図にしていじってみたらなんとかなったので、よければ参考にしてください。
最後まで読んでいただきありがとうございました。
プログラミング初学者がまとめる〜Unicornについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回は前回の続き？でアプリケーションサーバーの一つである、Unicornについて紹介します。最後の方にpumaとの比較も書いてみようと思います。
◯Unicornとは
Unicornとはアプリケーションサーバーの一つです。（アプリケーションサーバーの説明は前の記事を参照してください。）
◯Unicornの特徴
・マルチプロセス型である
Unicornはプロセスごとに通信処理をおこなうので、重たい通信があった場合そこでブロックされて全体が重くなってしまうことがある。
・起動の速さ、デプロイする際にダウンタイムが発生しない。
Unicornは、プロセスがmaster1つと複数個のworkerに別れていて、masterがソースコードを保持しており、実際に動くのはmasterのプロセスのコピーを持ったworkerプロセス群である。よって、ソースコードを読み込む必要があるのがmasterだけであり、起動が早くデプロイ時のダウンタイムもない。
また、Nginxがつなぐのはmasterのみなので、masterは各workerにロードバランサーのような形で負荷分散をしながらリクエストを送ることができる。
(ダウンタイムとは、常時動いていることが期待されるアプリなどが、停止・中断している時間のことを言う。)
・実際Webサーバとしても起動できる
UnicornとRackだけでRailsを動かすことも可能。しかし、プロセス数が少ないため、大勢のアクセスへの対処が難しいのが現実である。よって、プロセス数が多いwebサーバと合わせて使うことが理想である。またUnicornのドキュメントでもnginxと組み合わせることを推奨している。
◯unicorn と puma の違い
・unicorn はマルチプロセス、puma はマルチスレッド型である。（説明略）
スレッド（master）はメモリを共有し、プロセス(worker)はメモリを共有しません。通常、httpサーバーは複数のリクエストを独立に処理し、永続的なデータはデータベースに保存するので、マルチプロセスモデルの方が相性が良いです。しかし、マルチプロセスよりはマルチスレッドの方が一般にパフォーマンスは高いのです。
・レスポンスの差があるかも？
レスポンスを返すまでに数秒間かかるようなアプリケーションの場合、 unicorn を使用していると急激に遅くなるケースがあります。 そういう場合には puma などを使用するのが良さそうです。
◯では実際どちらを選ぶべきか？
今の私の知識・経験では、正直どちらの方がいいのか100点の回答を出すことができません！笑
しかし比較して分かったのは、アプリケーションの種類にもよるけど、pumaがマルチスレッド型なので処理が遅くなる可能性が低いと言うことがわかりました。PF見せる時を想定すると、処理が遅くなる可能性があるUnicornよりnginxの方がいいのでは？と言う結論に至りました。実際にどちらも導入してデプロイをしたことがあるのですが、肌感で差は感じませんでした。。。
◯まとめ
今回はUnicornについてと、webサーバーについての現時点のまとめを考えてみました！
もっと学習しないと性能を存分に発揮できないと感じたので、機会があればもっと深く勉強しようと思います。
今回も最後まで読んで頂き、ありがとうございました！！
プログラミング初学者がまとめる〜pumaについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
pumaとは
pumaとはスピードと並列性を追求したRubyのアプリケーションサーバーである。 RubyでWebサーバーを作るときの標準となっているRackに対応しています。nginxの回であった通り、nginxは単体でRackと通信ができないため、Rackと通信できるアプリケーションサーバーが必要になります。その選択肢の一つとしてpumaがあります。またrails５から、pumaがデフォルトで導入されています。
そしてwebサーバーとしての役割を果たすこともできるのがpumaの特徴です。
pumaの特徴
pumaは、ユーザーからのリクエスト受け取りとアプリケーションサーバへ処理を投げるのが速いことが特徴です。スピードと並列性を追求したものとなっています。
またマルチスレッドで動くので、プロセスを増やす必要がないため、リソースが少ない中でも効率的にリクエストをさばくことが可能になります。
マルチスレッドとは
アプリケーションのプロセスを複数のスレッドに分けて並行処理する方式のことです。つまりアプリケーションの処理を必要に応じて複数を並行して進めることができるため、処理速度と精度が向上する特徴があります。
まとめ
今回はpumaに関してまとめてみました！
よく比較されるUnicornについて次回まとめ、比較等ができたらなと考えています。
最後まで読んで頂きありがとうございました！！
プログラミング初学者がまとめる〜nginxについてまとめてみようと思う。〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回はwebサーバーの一つ、nginxについてまとめていこうと思います。
よく比較されるAppachとの使い分けについても少し触れてます。よければ最後まで読んでみてください！！
◯nginxとは
apacheなどと同じwebサーバの一つです。
webサーバーのシェアは世界の40%くらいだそうで、appachと分け合ってると言う状況だそうです（2020年11月現在）。
◯nginxのメリット
・高速
・大量処理が得意
・設定は意外に容易
高速・大量処理が得意
例えば、Webサーバーの負担を軽くして処理速度を上げる手段として、「リバースプロキシ」や「ロードバランサー」などがあります。これらの実現にはNginxが動作方法の違いから向いています。（nginxは大量アクセスに対して、分散して処理を行う。appachは大量アクセスを一つにまとめてから処理を行う。）
またnginxの立ち位置はリバースプロキシです。つまり簡単なHTTPリクエストはnginxが担い、難しいリクエストはPuma+Railsに任せるということです
設定は意外に容易
nginxはappachより新しいwebサーバーであるため、設定ファイルの情報が少なかったり難しいと捉えられる時が多かったそうです。しかし近年のアップデートにより使いやすくなってきたみたい。
◯nginxのデメリット
・大量の動的コンテンツの処理に不向き(動画サービスなど)
・Rackは直接つなげることができない。→Unicornやpumaを挟む必要がある。
実際rackに接続できないので、nginxなしでpumaのみでいいのでは？と考えるかも？しれません。しかしnginxの処理速度の早さは評価が高く導入するパターンが多いです。
◯（番外編）なぜPFにnginxを導入するのか？
1,（appachに比べて）処理速度が速いこと。
2,動画コンテンツのアプリではないこと。
ここあたりをいい感じに言葉にすればいいのでは？とまとめてて思いました！！
◯まとめ
今回はnginxについて割と細かめにまとめてみました！
少しでも理解が深まるようでしたら幸いです！！
最後まで読んで頂きありがとうございました！！
