インフラを考える上で大事なこと
インフラに必要な知識といえば…?
AWS
Terraform
linuxの設定
コンテナ
↑も大事だけどインフラはレイヤーの概念で理解しよう
今回紹介するレイヤー
TCP/IPプロトコル群
クラウドインフラの責任共有モデル
プロビジョニングレイヤー
TCP/IPプロトコル群
コンピュータ同士をネットワークでつなげるときの参照モデル
クラウドインフラではおもにここが扱われる
層の違いは扱えるデータの粒度の違い
上位層に行けばいくほどユーザが欲しいデータ
L7であればそのプロトコルが使うデータを扱える
URLやHTTPヘッダー
L4であればIPとポート番号が使える
L3はIPのみ
L2はより物理的なスイッチング
L1は電気信号
スイッチ、ファイアウォールを考えるときに使う
L7レイヤー
HTTP/SMTP/DNSなどアプリケーションで用いるデータをやり取りするときに使う。
例えばURLのパスベースでリクエストを分けるときはL7レイヤーでスイッチできないといけない
L4レイヤー
Security GroupなどTCP/IPレベルでリクエストを分けるときに使う
例えば社内からのアクセスのみ許可
同一ネットワークからのプライベートアクセスのみ可
すべてを事細かに知る必要はないが、要件によって技術選定できるようにはしておきたい
使用しようとしているネットワーク機器がL4スイッチまでしか対応していなかったら…?
その到達先でnginxなどのアプリケーション・サーバーを用意し、L7スイッチできるようにする。
プライベートネットワークとパブリックネットワークの違いは…?
L4レベルで外部に公開されるかどうかの違い
プライベートであればそれ以上の階層でどういう実装を行っても外部からのアクセスはできない
クラウドインフラの責任共有モデル
AWSが出してる責任共有モデル
クラウドインフラになることによって下記を考える必要がなくなった
サーバーを設置しているところで災害が発生したらどうしよう
データセンターに対する物理的な侵入防止策
PaaSやFaaSなどで使われているホストOSのメンテ
逆に下記は気をつけなければならない
ゲストOS
ネットワーク設定
アプリケーション
データの暗号化
アクセス権限の管理
クラウドインフラの中でもサービスによって責任範囲が異なる
EC2を使うなら、OSのメンテナンスはユーザ側にあるが、LambdaであればAWS側にある
MySQLをRDSに設置すればMySQLのアップデート管理を任せられるが、EC2に設置するとMySQLに関わる全てのミドルウェア管理をユーザ側が行う必要がある。
基本的にはクラウドインフラが提供しているマネージドサービスを使うのが良い。
プロビジョニングレイヤー
大きく分けて3つある
Bootstrapping
Configuration
Orchestration
Bootstrapping
OSの起動を行うレイヤー
クラウドインフラであれば基本クラウド側が担ってくれる
EC2であってもコンソール上でポチポチやれば任意のOSの環境が手に入る
Configration
ミドルウェアの設定
wgetなどのlinuxコマンド
phpやそれに付随するライブラリ
supervisorなどのプロセス管理ツール
など
Ansibleでの設定やDockerfileの記述がそれに当たる
Orchestration
アプリケーションのプロビジョニング
ソースコードの反映や、ロードバランサーへの登録を行う
AutoScaling + CodeDeploy + ALB
インスタンスが増えたときに、ソースコードが反映されてからALBの接続先に設定する
ECSやk8s
事前に設定した設定事項のとおりに、コンテナイメージからコンテナを起動し、クラスタに配置
まとめ
インフラを考える上での基本的なレイヤーを紹介
インフラを考える上では当然他の概念も知らないといけない
ただ、構成図をみて、「これは何をしているものなのか」「なぜこれが必要なのか」を理解するのには十分取っ掛かりになり得るものだと思っている。
ちなみに…
Terraformをテストする場合は
AWSのコンソール上でポチポチ
作成されたリソースに対してterraform import/
terraformer
でインポートするといい感じにコード化できる
ので、terraformを勉強すること自体はあまり意味がない…
Made with Slides.com