単語の意味を理解する
はじめに
「VPN」についての理解を整理しようとしていたら脱線して「言葉の意味」についての発散になってしまいました。
とりとめないですが一旦UPします
文脈で言葉の意味・階層が変わる
みなさんは「コーヒー買ってきて」と言われたら何を買ってきます?
依頼者があまり親しくない相手だった場合、「何がいい?スタバ?ドトール?それともセブンイレブンのコーヒー?」と詳細を一から確認する必要がある。
親しい友人、カップル間のやり取りであり、二人とも「スタバ大好き」という前提があった場合、ここでは「(スタバの)コーヒー買ってきて」という意味になる可能性がある。その場合、「サイズは?トール?ショート?」と具体的な質問からはじめられそう。
意味を理解するために
以下を理解していると、どんな文脈でも場面場面での意味を理解できそう
コア意味…辞書的な意味
頻出意味…コア意味ではないけど、この意味でつかわれることが多い意味
誤用…間違ってあてはめられた意味
IT業界の用語
業界に限らずだけど、特にIT界隈において「この単語は、今どういう意味で使われているか?」を意識することは重要。
「ネット繋がる?」(インターネット、社内ネットワークどっちの話?)
「クラウド使ってます」(SaaS系、IaaS系どっちの話?)
VPNの話
「VPN」と一言で表しても色々ある。
並べてみる。
・IP-VPN
・インターネットVPN
・広域イーサネット
これらをパッと並べたときに、しっかり各VPNを理解している人だったら「それとそれを並列で並べないでよ」と感じるんじゃないか。
たとえば、IPsec-VPNとSSL-VPNは「インターネットVPN」の1種類なので、同じ階層に並べたくはない。
あとは、広域イーサネットはVPNという分類になるのか?とも思うが、VPN関連と近いくくりでまとめられているWeb記事もちょいちょい見る。
IP-VPNとインターネットVPNも、一応並列で並べていい言葉な気はするけど、明快に判別するなら閉域網-VPN&インターネットVPNとかいう表現で表してはどうかって思う。
「名は体を表す」という感じで、名称がそのまま実体と紐づく言葉は覚えやすくていいなーと思う。誤解を招きにくくて。
いったん筆をおく。
NLB備忘録
はじめに
NLBをそれなりに触っています。
色々ハマったので備忘録としてブログを書いておきます。
NLBとは?
Elastic load balancerの選択肢のひとつ。
Network Load Balancerの略。
http/https以外の通信プロトコルを利用したい場合に利用する。
備忘録
ALBと共通する部分と、NLB特有の部分と両方ありますが、一旦気にせず書きます。
・オンプレミスからDNS名を指定して通信したい場合、オンプレ側かクラウド側のどちらかで名前解決する必要がある。
→当たり前のことを言っているようだが、どちらにするかで対応事項が変わるので意識しておく
→具体的には、利用するリゾルバの指定を行う。クラウド側のリゾルバを使う場合は、Route53 Resolverを利用する。
→オンプレからクラウド の名前解決では、「インバウンドエンドポイント」を作成する。
これがそれなりに高額なので注意。
・DNS名を指定して通信する場合は、NLBが物理的にどのAZに存在するかは気にしなくて良い。
ただし、DNS周りの事情で「固定のIP」指定で通信したい場合は注意。
IPアドレスは、特定のサブネットに所属するリソース。つまり特定のAZにも所属することになる。
・またNLBは、作成時指定したAZそれぞれに物理的なリソースは存在する。
→そしてデフォルトでは、指定したAZに物理的に存在するNLBを通る通信は、同じAZのターゲットにしかトラフィックが振り分けられない。
・が、「クロスゾーン負荷分散」を利用すれば、特定のAZの物理NLBを通る通信を、別AZに所属するターゲットにも振り分けることができる。
・クロスゾーン負荷分散はNLBしかできんらしい。
・なんで
もっと整理したいこと
・「クロスゾーン負荷分散」は何を解決する機能なのか?
・DNS名指定でNLBへ通信するとき、後ろのIPアドレスはラウンドロビンで振り分けられる?
・リスナーポートとターゲットポートの役割について
・なんでALBはクロスゾーン負荷分散できないのか?
・NLBを複数ゾーン構成にすることは料金に影響ある?
参考にした情報
NLBでオンプレ・AWSの様々なターゲットIPと重複するポートへの通信を振り分ける | DevelopersIO
→振り分け設計の参考になりそう。
→クロスゾーン負荷分散について認識。
Network Load Balancer(NLB)でクロスゾーン負荷分散が可能になりました | DevelopersIO
→わかりやすい。クロスゾーン負荷分散の意義がつかめる。
「AWSの基礎を学ぼう 第四十四回」に参加しました
はじめに
Transit Gatewayについての知識を固めたいため参加。
良い復習になった。
https://www.slideshare.net/secret/usJgIguOpzvhGo
雑メモ
・複数VPCや複数オンプレ環境との
・アタッチしてアソシエイトしてプロパゲートすれば
・「今後VPC個数を拡張していく予定はない」という場合はあまりコストメリットないので個別設定で良し
・AWSはMTUデフォルト1500固定→変更も不可
・世の中ではジャンボフレーム
・「Transit Gatewayを使えば管理が簡単になる」≠「セキュリティ」
・VPC単位でなく、AZ単位でENIを作る必要がある
・TGWアタッチメントENI専用のサブネット作成がおすすめ
→ルートテーブルをTGWのみの目的で管理できるため
・相互接続を制限したい時にTGWのみで制御するのは大変
・最大5000拠点を中継できる
→ただCIDRの重複はNG。個々重要ポイント
・VPC内での名前解決はデフォルトで可能
→VPCまたぐ場合Route53 Resolverエンドポイントの作成必要
・Multicast on AWS
→ちょっとインパクトよくわからず
・TGW Inter-Region Peering
・Network Manager
→リモート接続含めた接続性のモニタリング
まとめ
複数ネットワーク拠点(オンプレ、VPC)を接続するために習得ますとなサービス。
DirectConnectの知識も拡充して、実装できるとこまでいきたい。
VPCのDHCPとかRoute53 Resolverのインバウンドエンドポイントとか
はじめに
ちゃんとまとめようとすると筆が重くなるので、一旦メモレベルでアップしておく。
やりたかったこと
オンプレミスとクラウド(AWS)のハイブリッドな構成をとりたかった。
具体的にいうと、オンプレ→クラウドの名前解決を、クラウド側のフルリゾルバを使って名前解決要求をさばく構成。
詳細
オンプレ環境の容易が手間なので、異なる2つのリージョンの片方をオンプレ側、もう片方をクラウド側として実施。
その場合、それぞれの環境で以下を準備。
オンプレ側VPC
・接続元インスタンス
・オンプレ側ルーターインスタンス(Vyos)
・クラウド側のリゾルバを参照するためのDHCPオプションセット
クラウド側VPC
・カスタマーエンドポイント(オンプレ側ルーターを認識させるためのもの)
・Site to Site VPN接続
・接続先インスタンス
・Route53 Hosted Zoneによるプライベートホストドメイン
・Route53 Resolverによるインバウンドエンドポイント
実施手順
オンプレ側VPCの準備
・東京リージョンでVPC作成
・接続元インスタンス作成
・ソフトウェアルーターインスタンス作成
→適切なAMIを選ぶ
→EIPを付ける
・DHCPオプションセットはあとで
クラウド側VPCの準備
・シンガポールにVPC作成
・接続先インスタンスを作成
・カスタマーエンドポイントを作成
・VGWを作成
・Site to Site VPNを作成
・プライベートホストゾーンを作成
・インバウンドエンドポイントを作成
注意点
・Route53 Resolverの料金それなりに高い。検証とか個人使用の範囲で使うもんじゃない。
・VPN設定の際、ファイル編集は新しい情報を見る必要がある。文法変わってるところがある。
・どっちをオンプレ側に見立てるのか、そしてどっち側で何をする必要があるのかをイメージした方が良い。
・既存のDHCPオプションセットは編集不可。設定変更したい場合は新規作成する必要あり。
→作成したものをVPCに付け替えればVPC内のインスタンスには勝手に適用。
→リース更新のタイミングで設定は反映される。(数時間に1回とかのようだ)
参考:DHCP オプションセット - Amazon Virtual Private Cloud
参考
インバウンドエンドポイントを使用して、リモートネットワークからプライベートホストゾーンのレコードを解決する
6月の目標
降ってくるものに場当たり的に対応して気付いたら月日がたっている感覚がある。
もうちょっと現状をちゃんと把握して、方向性をコントロールしていきたいなという気がするので、今後は月末に当月の振り返りと次月の目標設定を行うことにする。
2021年やることと進捗
もう2021年も折り返しそうですが、月のやることに落としづらそうなので今更設定します。
仕事は関係なくあくまで私生活上の目標。
・資格取得
AWS資格11種コンプリート
→実際は来年の2月くらいまでに…
・技術アウトプット
技術ブログ執筆20件
技術LT登壇5件
5月の振り返り
スキル面
・資格勉強何もせず
→仕事で余裕がなく触れなかった
・読書 3冊
→別記事で詳細書こう
6月の目標
・DOP取得
→予約しよう
・読書2冊
・技術ブログ4件
・毎日12時までに寝る
雑記
ブログに書いとくことで後から見れるようにする。
このやり方は面識もなにもないAWS関係の仕事されてるすごい人をパクっている。
一旦ゆるめに続けてみて、良い影響があるか経過を見てみる。
【読書メモ】情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則
読んだ本
情シス・IT担当者[必携] システム発注から導入までを成功させる90の鉄則 | 田村 昇平 |本 | 通販 | Amazon
読んだ動機
システム導入の検討段階から導入、運用までを体系的に学んでおきたいと思い購入。
学んだこと
・RFPはベンダーに声をかける前に作成する
・ベンダーの評価基準はあらかじめ定めておく
・導入効果を示すため数値化をしておく
・マスターデータの扱い、データ連携の要件は明確にしておく
・受入テストは4種類(機能テスト、システム連携テスト、シナリオテスト、新旧環境比較テスト)
感想
私はどちらかというとベンダーの立場ではある。
だからこそ、ユーザー側が持つべき観点が解説されてる本書はとても参考になった。
疑問
・マスターデータの信頼性はどうやって担保する?
・データ連携の松竹梅は?ETLの分類は?
・受入テストはどう進む?具体的に何をする?どのツールを使う?
・弊社テストツールのカバー範囲は?
【読書メモ】Webを支える技術 -HTTP、URI、HTML、そしてREST
書籍
Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) | 山本 陽平 |本 | 通販 | Amazon
読んだ動機
AWSソリューションアーキテクト プロフェッショナル の資格勉強をしているときに、「Webについて理解すれば、AWSのことももっと理解できそう」と感じたのがきっかけ。 Webについて学べそうな本をざっと探してみたところ、本書は程よい入門性と内容の充実度のバランスがよさそうだったので購入。
概要
本書では、「Web」というとらえがたい言葉を、発達の歴史・関連用語などを一つずつほぐしながら順を追って解説していく。 HTTP、URI(あるいはURL)、HTMLなどの用語は、多くの人が意味を理解せずになんとなく触れている。 (ある意味すごいことだな。。) これらの用語を、「Web」という概念に対してどういう関係性を持つものなのか理解できる。
いくつか「覚えておこう」と感じた点を以下にまとめる。
RESTとは
ググってみてもイマイチわかったような気になれないREST。 本書の説明を読んで少し輪郭が見えてきた気がする。
RESTとは、以下の特徴を備えたWebの「アーキテクチャスタイル」のことのようだ。 必ずしもすべてを満たす必要はないが、すべてを満たす「RESTらしい」アーキテクチャのことをRESTfulと呼ばれる。
1.クライアント/サーバ型である
システムを、アプリケーション提供者としてのサーバと、受け取る側のクライアントに分けていること。 サーバとクライアントを分割することで、システム全体の柔軟性を保てる。 たとえば、アプリとしてのデータ保持や主な処理はサーバ側で実行するため、クライアント側での実装は最小限で済むことなどがある。 クライアント側での実装負荷が下がることで、クライアントをマルチデバイス化することもできる。
2.サーバがステートレスであること
ステート とはアプリケーションの状態のこと。 「ステートレスである」とは、サーバがクライアントのアプリケーション状態を保持しないことを指す。 ステートレスを保つことにより、サーバの実装はシンプルになる。 ただし、実際のWebサービスではサーバがステートフルになっているケースも多い。
3.キャッシュ機能を持つ
キャッシュとは、サーバから取得したリソースをクライアント側で保存しておくこと。 キャッシュすることで、クライアントとサーバ間の通信を減らし、サーバの負荷を下げられる。 ただし、タイミングによってはクライアントが古い情報を取得してしまう欠点もある。
4.統一インタフェースを実装している
インタフェースとは、2つの要素がお互いやり取りするための接地面のこと。 そして、「統一インタフェース」とは、その接地面でのコミュニケーション方式を統一している状態のことを指す。 たとえば、8つしかメソッドを持たないHTTPを統一インタフェースとすることで、アーキテクチャ全体がシンプルになる。
5.階層化システムである
「統一インタフェース」を実装していることの副産物にもなるのが、「システムを階層化しやすい」こと。 インタフェースが統一されていることで、接地面の実装はシンプルになる。 そこで、役割ごとにサーバを分割、つまり階層化しやすくなる。 システムを改装に分けることで、各階層ごとに拡張性を持たせることができ、無駄のないアーキテクチャとしやすい。
6.コードオンデマンド
サーバ側から提供されたプログラムを、クライアント側で実行すること。 クライアント側での機能拡張が行いやすくなる。 ただし欠点として、サーバからクライアントへの通信におけるプロトコルの可視性が落ちることがある。
WebサービスとWeb API
この2つの用語を分けて認識しておくことは重要。 APIとは、プログラムからアプリケーションを利用するためのインタフェースのこと。
Webサービスとは、私たちが普段利用するWebアプリケーションを指している。つまりWeb利用における「人間用」の利用画面というところ。 Web APIとは、プログラムがWebアプリを利用するためのインタフェースのこと。つまりWeb利用における「プログラム用」の利用画面。
感想
まったくの初学者にはおそらく歯ごたえがありすぎる。 「OSI参照モデルを大まかに理解してる」かつ「L7のHTTPについてもっと掘り下げたい!」という方にはちょうど良い内容かもしれない。 実際にWebサービスを自分で実装する際に参照するのもよさそうだ。