プログラミング初学者がまとめる〜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について割と細かめにまとめてみました！
少しでも理解が深まるようでしたら幸いです！！
最後まで読んで頂きありがとうございました！！
プログラミング初学者がまとめる〜webサーバーとアプリケーションサーバーの流れについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回は前回の続きで、webサーバーとアプリケーションサーバーの流れに焦点を絞ってまとめていこうと思います！！railsアプリを前提に書いていくのでご了承ください。
◯Rack
今回の話をするにあたり一つ紹介したいのがRackについて知っておいて欲しいです！
Rackは簡単に言うと、アプリケーションサーバーとアプリケーションを橋渡しの役割を果たしているものです。
もっと具体的に言うと、RackはRailsのようなRuby製のwebフレームワークとアプリケーションサーバーの両方が話せる共通言語のようなものだと考えてください。両者は別々の言語で書かれており、直接会話ができません。しかしRackは両者の共通言語を理解できるので、RailsはUnicornと話せますし、UnicornはRailsと話せるので、railsがアプリとして機能するわけです。
◯再度流れを確認する
1.webリクエストはwebサーバーが受け取ります。
2.リクエストが静的コンテンツであれば、webサーバーがレスポンスを返す。
3.webサーバーが処理できない場合は、アプリケーションサーバーにリクエストを送る。
4.アプリケーションサーバーからRackを通して、アプリケーションにリクエスト(←NEW)
5.アプリで処理を行った後、Rackを通じてアプリケーションサーバーへレスポンスを返す(←NEW)
6.アプリケーションサーバーからwebサーバーへレスポンス、webサーバーがクライアントにレスポンスを返す
◯流れに具体名を入れてみる
1.webリクエストはwebサーバーが受け取ります。（Nginx・Apache）
2.リクエストが静的コンテンツであれば、webサーバーがレスポンスを返す。（Nginx・Apache）
3.webサーバーが処理できない場合は、アプリケーションサーバーにリクエストを送る。(Nginx・Apache→Unicorn・Puma)
4.アプリケーションサーバーからRackを通して、アプリケーションにリクエスト（Unicorn・Puma→Rack→アプリ）
5.アプリで処理を行った後、Rackを通じてアプリケーションサーバーへレスポンスを返す（アプリ→Rack→Unicorn・Puma）
6.アプリケーションサーバーからwebサーバーへレスポンス、webサーバーがクライアントにレスポンスを返す（Unicorn・Puma→Nginx・Apache）
◯なぜwebサーバーとアプリケーションサーバーを構築する必要があるのか？
これまでを聴いていると万能なRackだけあれば、うまく処理できるように思えるかもしれません。
しかしRackだけだとWebサーバがなく、高速な処理や高負荷に耐えることができなません。nginxやunicornといったwebサーバを用意することでうまく負荷分散をして、大勢のクライアントからのアクセスに対応できるようにしている。
◯まとめ
今回はwebサーバーとアプリケーションサーバーの流れについて少し細かくまとめてみました。
普段なんとなくサーバーを立ち上げていますが、裏ではこんなことが起きているんですね！
次回からはwebサーバーやアプリケーションサーバーについて細かく書いてみようと思います！
最後まで読んで頂きありがとうございました！！
プログラミング初学者がまとめる〜webサーバーとアプリケーションサーバーについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
今回から何回かにわたってwebサーバーとアプリケーションサーバーについてまとめていこうと思う。
初回の今回はwebサーバーとアプリケーションサーバーについてざっくりとまとめてみようと思います。
◯webサーバーとは
webサーバーはユーザーから送られてきたリクエストを受け取り、なんらかの処理を加えるプログラムです。webサーバーのみで対応できる内容であればそのままレスポンスを返し、無理なら他のサーバーに橋渡しをしているイメージです。
具体的にはリクエストがHTML、CSS、画像ファイルのような更新しない限り同じ表示コンテンツを表示する静的なwebコンテンツだった場合はwebサーバーがレスポンスを返します。一方で、クライアントごとで表示内容を変化させる処理が必要な動的なwebコンテンツの場合、webサーバーはアプリケーションサーバーへとリクエスト（橋渡し）をします。
ex） Nginx・Apache
◯アプリケーションサーバーとは
アプリケーションサーバーは、Webサーバーを通して受け取ったリクエストを処理し、HTMLなどをウェブサーバーへ返却する役割を果たします。またアプリケーションサーバーはアプリケーションを動かしているそのものと言えます。
アプリケーションサーバーはあなたのコードを読み込み、アプリケーションをメモリに保持します。アプリケーションサーバーはwebサーバーからリクエストを受け取ると、Railsアプリケーションにそのことを知らせます。アプリケーションがリクエストを処理すると、アプリケーションサーバーはそのレスポンスをwebサーバーに返します。
ex)Unicorn、Thin、Rainbows、Puma
◯それぞれの役割
webサーバーは複数のアプリケーションを一度に処理したり、アセットを素早くレンダリングしたり、リクエストごとに発生する多くの処理をさばいたりしてくれます。本番環境ではwebサーバーを置くことが多いです。一方でローカル環境ではwebサーバーを使わずアプリケーションサーバーのみで動かすことができる。
◯流れをまとめてみる
1.webリクエストはwebサーバーが受け取ります。
2.リクエストが静的コンテンツであれば、webサーバーがレスポンスを返す。
3.webサーバーが処理できない場合は、アプリケーションサーバーにリクエストを送る。
4.アプリケーションサーバーからアプリにリクエスト・処理を行った後、webサーバーへレスポンスを返す
5.webサーバーがクライアントにレスポンスを返す
◯まとめ
今回はwebサーバーとアプリケーションサーバーについてまとめてみました。
自身でも理解がぐちゃぐちゃになっていたので、いい整理ができました！
次回は流れについてもう少し細かく書いてみようと思います。
最後まで読んで頂きありがとうございました！！
プログラミング初学者がまとめる〜docker-composeについてまとめてみようと思う。ざっと理解する編〜
＊自身の言葉で書いてますので、間違っていることもあるかと思いますが、ご了承ください。訂正のコメントを頂けるとありがたいです。＊
◯docker-composeとは
簡単に言うと、複数コンテナの設定ファイルである。
Dockerのベストプラクティスとして１コンテナ１サービスとされている。つまりコンテナ１つでアプリケーションを作ることは推奨されていない＝複数コンテナを作成・管理する必要があるということです。
docker-composeでは、複数コンテナからなるサービスを構築・実行する手順を自動的にして、管理を容易にすることができます。docker-composeコマンドでdocker-composeファイルの設定を読み込んで全てのコンテナサービスを起動することが可能です。
Docker Composeでは、Dockerビルドやコンテナ起動のオプションなどを含め、複数のコンテナの定義をyaml（ヤムル）ファイルに書き、それを利用してDockerビルドやコンテナ起動をすることができます。一つの簡単なコマンドで複数のコンテナを管理できるようになります。
◯docker-compose.ymlファイルとは
yaml形式でdockerコンテナに関する起動オプションを記述したファイルになリマス。
このファイルに記載されている内容は基本的にdocker build docker runコマンドで指定することができるオプションになるが、yamlファイルにまとめることでサービスを俯瞰的に見ることができます。(細かい情報は今回は省略)
（例）
version docker-composeのバージョン
service 管理するコンテナの指定
◯使うためのステップ
1.Dockerfileの作成
2.Docker-compose.ymlを作成する
3.docker-compose buildコマンドでイメージをビルド・コンテナを作成する
4.docker-compose up でコンテナを起動する
◯まとめ
今回はdocker-composeのアウトラインをまとめてみました。
ymlファイルの記述方法を細かく学習すれば、docker-composeができるようになるはずです！！また別の記事でまとめてみようと思います。
最後まで読んで頂きありがとうございました！！
