ネットワーク・クラウド

2022/11/06

Go言語でできることは何なのか

Go言語でできることは何なのか、について考えたことをメモ。
全くのGo初心者がいろいろ考えたことのメモ。
間違えていたら後で直す。

【参考】
とほほのGo言語入門 - とほほのWWW入門

Go言語(golang)とは? 特徴・できること・将来性を徹底解説 | 【テックストックMAGAZINE】エンジニア向けスキル・キャリア情報

Go言語にできることってなに?人気の理由をくわしく解説 | 株式会社パソナ(旧パソナテック)|ITエンジニア・ものづくりエンジニアの求人情報・転職情報

Go言語の強みと得意分野を探る(上) - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)1 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(中)2 - Go言語の強みと得意分野を探る:Computerworld

Go言語の強みと得意分野を探る(下) - Go言語の強みと得意分野を探る:Computerworld

Go言語でできることとは?Go言語で作れるアプリの事例を紹介 | プログラミング大陸

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Go言語の書籍を色々読んでみて色々気づきはあった。

Go言語は、マイクロサービスアーキテクチャを実装するプログラミング言語であるらしい。
色々記事を読んでみて、Go言語は、CLIやAPIを作るのに最適な言語であると感じた。

他システムがWebサーバーからデータを取得したり更新しようとする時、APIという公開IFを設けて疎結合な設計にしたい。
Go言語であれば簡単にHTTPでやり取りできるのでWebサーバを立ち上げる必要もなく、普通のクライアントアプリケーションみたいに作ればいい。
また、Go言語では並行プロセスの実装も割と簡単なので、負荷に応じてプロセスを増やせば良く、クラウド上でAPIを公開するためのアプリとして最適。

Go言語でCLIを作るイメージは、Unixコマンドを作るイメージだろうか。
Unixであれば、/binの中に各種コマンドがexeで配置されている。
別システムがバッチ処理をキックしてシステム連携したい場合、CLIという公開IFを叩けば良い。

そんなことを考えると、Go言語はかなり特殊な状況で使うもののように思う。
業務ロジックを実装するレイヤではなく、OSやアプリの間で処理するためのミドルウェア、ないしフレームワークみたいな役割を持つレイヤで実装すべき。

また、Go言語はクラウドと相性がいい。
Go言語はクロスプラットフォームでバイナリファイルを作れるので、CLIやAPIに向く。
また、Go言語で作ったバイナリファイルのサイズを小さくできれば、クラウドのリソースを少なく押さえられる。
また、メソッド呼び出し時のアプリ起動時間を短くでき、並行プロセスで走るアプリの起動時間(ロード時間)も短くできる

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

つまり、Go言語はクラウド上でCLIやAPIを実装したプログラムに特化した言語なのだろう。
だから、マイクロサービスアーキテクチャと相性が良いと言われているのだろう。
そして、マイクロサービスアーキテクチャはドメインごとの境界で使われるので、ドメイン駆動設計とも相性がよく、それらの設計技法と密接に絡む。

そんなことを考えると、一昔前のオンプレ環境でのWebシステム構築で経験されて蓄積されたアーキテクチャ設計技法は古くなっており、クラウドに特化したアーキテクチャ設計技法をもっと探究していくべきだ、という方向性が出てくるのだろう。
このあたりの考え方もいろいろ調べている。

| | コメント (0)

コンテナはサーバーレスアーキテクチャのための1つの技術

コンテナとは一体何なのか?
コンテナとはサーバーレスアーキテクチャのための1つの技術にすぎない。
AWS初心者のラフなメモ。

【参考】
202106 AWS Black Belt Online Seminar CON110 なぜ今コンテナなのか

JAWS-UG初心者支部#50 ContainerをCICD PileLineでDeploy!! - connpass

[JAWS DAYS 2022] ハンズオン~コンテナサービスをCI/CDパイプラインでデプロイしよう~

AWS初心者向けにハンズオンの勉強会があったので参加してみた。
手順書に書いてある通りに、コマンドを叩くだけでVPSやAPI Gatewayなどの環境が全て作られて、CI/CDパイプラインを試せる。
AWSの実戦経験がないので全然分かっていないが、実際に動く環境を作れて、実際に試して試行錯誤できる経験を得た。
とても良かった。
AWSはたくさんのサービスが既にあるので、それらを組み合わせるだけで開発環境やSaaSを簡単に立ち上げられると実感した。

コンテナとはいったい何なのか?
コンテナとは、VMとWebアプリケーションを一体化したものみたいなイメージ。

コンテナとはどのようなもの?クラウドサービスを動かすのに必要不可欠 | クラウドエース株式会社

Dockerは何がすごいのか?
コンテナを簡単に作れてDeployできること。
クラウド上にDockerファイルをアップロードしてrunすれば、簡単にWebアプリケーションを実行できる。
既にDockerイメージはたくさん配布されている。

なぜコンテナが必要なのか?
VMで仮想サーバを建てて環境構築するだけでは、Deployや運用の手間がかかる。
クラウドでVMとWebアプリケーションを一体化したコンテナで配布すれば、いつでも最新版のWebアプリを立ち上げられる。
つまり、Webアプリケーションがどんどんバージョンアップするたびに、コンテナで新規にデプロイすれば、いつでもクリーンな環境で立ち上げられる。

すると、コンテナをもっと進化させればサーバーそのものが要らないんじゃないの?となる。
AWSラムダがそんな感じだろうか。

今回のハンズオンでは、AWSでCICD PileLineを作る前にAWS VPCをすべてコマンドで作った。
一方、オンプレであれば、ルータを導入してネットワークアドレスを切って、その上にサーバーを構築して、ソースコードをビルドする環境も作ってデプロイして、という手順が必要になる。
だから、AWSは全くの初心者だが、AWS特有のコマンドを叩きながら、なるほど、こういうネットワークを作りたいのね、とか、こういうサーバー構成にしてデプロイしたいのね、とか、色々考えるところがあった。

プログラミングはブロックを積み上げる感覚に似ているが、AWSのサーバー構築もいろんな形のブロックを当てはめて積み木を作っている感覚だった。
この面白そうな感覚はもう少し掘り下げたい。

| | コメント (0)

2022/10/16

クラウド上の開発がJavaに与えた影響は何なのか

クラウド上の開発がJavaに与えた影響は何なのだろうか。
考えがまとまっていないがラフなメモ。
自分はAWSも知らないし、Go言語も知らないので、間違っていたら後で直す。

【参考】
Javaがサーバレスに至るまでの道のり

元JavaエンジニアがGoに感じた「表現力の低さ」と「開発生産性」の話 - DMM inside

Ruby->Go->Scalaという習得順序がエンジニアの爆速の成長に最適である理由 - Qiita

Javaがサーバレスに至るまでの道のりの記事を読むと、いかに軽量のWebアプリケーションを実現するか、に注力しているように思える。

従来のWebアプリケーション開発では、PerlのCGIのようなプロセス指向ではなく、JavaのServletのようなマルチスレッドの方が無駄にリソースを食わず、効率が良いと歌われていた。

しかし、サーバーレス環境では、AWS Lambdaのようにアプリをキックするような仕組みなので、アプリの処理時間だけでなく、アプリのロード時間も短いほど優位だからだ。
サーバーレス環境では、アプリを常駐させて、マルチプロセスで動く。
そして、処理が終わり、無駄に多くなったプロセスはすぐに破棄される。

つまり、クラウドでは、DockerやK8sのようなコンテナのおかげで、アプリ環境を使い捨てにできるメリットがある。
アプリも、負荷分散に応じて必要なだけ常駐プロセスを増やして、不要になれば捨てればいい。

すると、アプリのビルド、デプロイの時間も短い方がいい。
さらに、「起動時間がレスポンスタイムに含まれる」ために、アプリの起動時間も短くできれば、サーバーレス環境ではレスポンスタイムをもっと短くできて、使い勝手が良くなる。

そういう発想がJavaにどんな影響を与えているのか?
クラウド上の開発がJavaに与えた影響は何なのか?

たまたま、Javaのモジュールシステムの話の中で、jlinkコマンドがなぜ必要なのか?という話があった。
JDK9以後は、JREが配布されないので、Javaファイルを実行できない。
そこでjlinkで実行ファイルを作る必要があるという話だったが、さらにもう一つ興味深い話があった。

Java Module System 入門 その1 - YouTube

Java Module System 入門 その2 - YouTube

jlinkコマンドを使うとランタイム専用アプリを作れるが、必要なJDKライブラリだけを読み込んで、Jarファイルを作成する。
すると、jlinkで作られたランタイム専用アプリのサイズは、従来のランタイム専用アプリのサイズよりもかなり小さくなる。
不要なライブラリを除いているからだ。
実際、デモ画面では200Mから30Mまで小さくできた例があった。

つまり、jlinkコマンドを使えば、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
その分、クラウドのリソースを抑えられるし、アプリの起動時間(ロード時間)も短くできるメリットが出てくる。

すなわち、jlinkコマンドはクラウド上で配布するアプリに適合するように作られたものなのだろう。
Javaもクラウドに特化したアーキテクチャ設計を取り込んでいるのだろう。

そんな話を聞くと、サーバーレス環境のアプリでは、ランタイム専用アプリはバイナリファイルでサイズが小さいほど優位性が高いことになる。
マイクロサービスの実装言語はGoが主流であると聞くが、その理由は、Goで簡単にバイナリファイルが作れて、さらにそのサイズが小さいので、性能的にも優れている点があるのではないだろうか?
そして、Javaもそういう流れの設計手法を取り入れるために、jlinkコマンドのようなアーキテクチャが必要になってきたのではないだろうか?

ここで、クラウド上のシステム設計では、ドメインごとにアプリを細分化したマイクロサービスアーキテクチャが流行していて一般的になってきている。
マイクロサービスアーキテクチャが必要な理由は、普通のWebシステムでもクライアントからのアクセスがブラウザだけでなく、スマホだったりタブレットだったり、色んな端末に対応する必要があるので、公開APIを通じて制御できるよに、色々分割したほうが楽になる点があるだろう。
また、逆コンウェイ戦略のように、システム開発しやすいチーム組織の観点で設計すると、小さなコンポーネントの集まりになるようにシステムを分割して、マイクロサービスアーキテクチャで連携できるようにした方がよい点もあるだろう。

マイクロサービスアーキテクチャのそんな特徴を活かすには、おそらく、Go言語やjlinkコマンドのような実装言語やビルド方法も必要になってくるのだろう。

そんなことを考えると、クラウド上のシステム開発では、フロントWebシステムをRubyやJava、Pythonで作ったとしても、AWS lambdaやマイクロサービスの部分はGo言語やjlinkを使う、といったように、複数のプログラミング言語を適材適所に当てはめて開発する必要性があるのではないか。
つまり、クラウド上の開発は、単にコンテナ部分のアーキテクチャを使いこなすだけでなく、複数のプログラミング言語を適材適所で使い分けるノウハウも必要になってくるのだろう。

この辺りは妄想に近いかもしれないので間違っているかもしれない。
ただ、クラウドというアーキテクチャは、Webリソースをふんだんに使える富豪プログラミングを可能にしたからこそ、それに特化した設計手法がどんどん現れているのだろうと思う。

この発想が正しいのか、これから検証していく。

| | コメント (0)

2022/07/31

WireSharkの入門動画が分かりやすい

WireSharkの入門動画が分かりやすかったので、自分用にリンクをメモ。

【参考】
【#16 ITニュース】WireSharkを使ってDHCP通信の謎を解く - YouTube

【#16 Wire Sharkを使って見た】セキュリティのお勉強 - YouTube

【#17 Wire Sharkを使って見た 2】HTTPS TLS セキュリティのお勉強 - YouTube

【#19 Cookie 】Wireshark 解析 セキュリティのお勉強 - YouTube

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門はインフラエンジニア向けの良本だ: プログラマの思索

IPアドレッシングの計算方法: プログラマの思索

GNS3上でネットワーク図を作って、pingを色々試せるようになったが、どんなパケットが流れているのか、知るにはWireSharkが必要になる。
GNS3では、WireSharkが付属していて、ルータ間、スイッチ間のパケットを見れる。
しかし、ネットワーク初心者にとってWireSharkは難しい。
理由は、WireSharkで表示されるデータをどのように見ればよいか、分からないからだ。

書籍も色々読んでみたが、実際に動かしていないからイメージもできない。
だが、動画を見て、実際に動くところを見てようやくイメージが湧いてきた。

インフラエンジニアの人に聞くと、スイッチやルータでオンプレのネットワークを作ったとしても、何か障害があれば、WireSharkを見る時が多いらしい。
実際にどんなパケットが流れているのか、見る必要あるらしい。

特に2020年頃から、いろんな分野の解説サイトの動画が出てきて、非常に便利になったと思う。
プログラミングもネットワークも、実際に動かしてみなければ理解しづらい。
そういう意味では、今は動画を見て、手っ取り早く初心者レベルをクリアすればいいのだろう。
基本的な概念さえ押さえれば、後は、書籍や勉強会などでいくらでも知識の幅も深さも広げられる。

| | コメント (0)

2022/01/09

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ

「プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ」というツイートを見つけたすごく共感した。

【参考】
Rui UeyamaさんはTwitterを使っています 「少数派の意見かもしれないけど、プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じで、数学が関係ある感じがあんまりしない。」 / Twitter

結城浩さんはTwitterを使っています 「@rui314 デバッグしてるときと証明読んでるときはなんか似てる。素直に読みつつ穴探ししてるみたいな感覚。」 / Twitter

英語勉強中さんはTwitterを使っています 「@rui314 めちゃくちゃわかります。僕は書いてるとき数学のことなんか考えてないです」 / Twitter

akipiiさんはTwitterを使っています 「プログラミングはこの感覚に近いな」 / Twitter

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラマに必要なスキル: プログラマの思索

プログラムを書いている時、数学の知識を使っているかと言われるとそうではない気がする。
むしろ、APIやFWのライブラリをまずは頭に叩き込んでおき、自分が実装したい目標に対して、それらAPIをどうやって組み合わせて意図通りに動かすか、に注力している。
ちょうど、ブロックで巨大な積み木を組み立てている感じに似ている。

だから、「プログラミングしてるときはでっかいピタゴラ装置を作ってるみたいな感じ」にはとても共感するし賛同する。

たとえば、RDBでSQLをデータ抽出したり、機械学習や深層学習のライブラリを使って母集団を推定したり、マーケットを予測したり、Web上の通信を暗号化したりする時、数学の理論はAPIやライブラリの中に隠れてしまっている。
それらライブラリを呼び出すだけで、高尚な理論を使えるのは素敵だが、だからと言って、プログラミングが楽になっているわけではないと思う。

一方、やりたいことを実現するには、PythonやRDB、Webサーバー、Dockerなどの開発環境を揃えて、Githubで構成管理し、CIツールでビルド&デプロイできるようにして、Jupyter を動かせるようにしたり、IntelliJなどの開発環境を構築したり、とプログラミングの前準備がすごく多い。
普通の初心者はこの部分で挫折するのだろうと思う。

僕自身、新しい環境を揃えてプログラミングスタイルを覚える時は割と苦痛に感じる時もあった。
Ruby on Railsもそうだし、AWSでの環境構築、GNS3でのCiscoルータ&スイッチの環境構築の時もそうだ。
Python+Anacondaはまだマシだった。
プログラミングは奥が深い。

| | コメント (0)

2021/11/07

東大の講義内容が「AWSではじめるクラウド開発入門」本で出版されたらしい

東大の講義内容が「AWSではじめる クラウド開発入門 (Compass Data Science)」本で出版されたらしく、評判がよいのでメモ。

コードで学ぶAWS入門

AWSではじめる クラウド開発入門 | マイナビブックス

tomomano/learn-aws-by-coding: コードで学ぶAWS入門

Keisuke NishitaniさんはTwitterを使っています 「クラウド開発って何かと思ったら東大の講義内容らしい。今って大学でAWS習ったりするのか AWSではじめる クラウド開発入門 (Compass Data Science) https://t.co/HlJLizJ5QV」 / Twitter

是村 @ 多言語学習 & カスタマーサクセスさんはTwitterを使っています 「@Keisuke69 元はこれだと思うんですが、これの2020年度版を見てこんなの大学で教える時代なんだなーと思ってました。 https://t.co/HeZ4eQW1Hm」 / Twitter

Keisuke NishitaniさんはTwitterを使っています 「@JKoremura あーこれ!ちょっと前に話題になってたやつですよね。こういうの大学で教わるのはすごい時代ですよねー」 / Twitter

是村 @ 多言語学習 & カスタマーサクセスさんはTwitterを使っています 「@Keisuke69 いやー、ほんとそうです。そのうち何処かのタイミングでは、中途よりも新卒取る方が実践向きみたいな時期が来るかもですね。」 / Twitter

Shotaro SuzukiさんはTwitterを使っています 「@Keisuke69 これ先週読了しました。とっかかりとして良い内容ですね。」 / Twitter

最近、AWSに触っているがまだまだ本質を分かってない。
何となくEC2を立てて、色んなサービスを組み合わせれば動くのだが、何か分かった気がしない。
たぶん、もっと実際のアプリを作らないと、経験して初めて分かった気にならないのだと思う。

ツイートを読むと、東京大学2021年度S1/S2ターム システム情報学特論 "AWSを使ったクラウドコンピューティング入門" 講義資料が書籍として出版されたらしく、割と評判が良さげ。
ハンズオンでチャットボットを作るみたいだが、サーバーレスや機械学習、ディープラーニングまで触れられるのは、AWS初心者にとっては良さげ。

こういう講義ノートを読んでいると、下記ツイートのように、メインフレームのCobol開発者やオンプレミスの業務系WebシステムのJava開発者は、自分のスキルを棚卸しして、もう一度新しい技術を勉強し直す気概が必要だろうと思う。
過去の経験だけで仕事できる時代は終わった。
中年や年寄りにはそんなに甘くない。

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「ざっと眺めたところクラウド開発といいつつEC2、Docker、サーバーレスといった足回りの話だけでなく、深層学習やらチャットボットの作成やら諸々ウォークスルーでハンズオンも充実してて、今時は前期課程でここまでやっちゃうのか高速道路スゲーぞってなったので、取っかかりの入門書としては良さげ」 / Twitter

Masanori Kusunoki / 楠 正憲さんはTwitterを使っています 「東大だけに自作CPUみたいにクラウドをつくる話を期待したらAWS上での開発か。学生時代くらいはラズパイ並べて自作クラウドをつくるとか贅沢な時間を使って欲しいけど、今時の若手はUTPケーブルの圧着もサーバーのラッキングもやったことなくサーバーはクリックすると生えてくる感覚という印象(老害)」 / Twitter

easter2501さんはTwitterを使っています 「若手が仮想化やクラウドに特化してくるならロートルはさらに泥臭い領域に縄張りを求めた方が生存率は上がるだろうな。 当然クラウドの勉強もしなきゃならんが。」 / Twitter

| | コメント (0)

2021/11/03

DockerとVirtualBoxの違い

DockerとVirtualBoxの違いをメモ。
インフラ初心者の自分のためのメモ。

【参考】
Dockerとは何か?初心者にもわかりやすく仕組みやメリットを解説

「Docker」を全く知らない人のために「Docker」の魅力を伝えるための「Docker」入門 - Qiita

VirtualBox - DockerとVirtualBoxの違いについて|teratail

DockerとVirtualBoxの違い - Qiita

「Vagrant」と「Virtual Box」の違い - Qiita

初心者のための Vagrant, Chef, VirtualBox の関係 - Qiita

vagrantのネットワークについて - Qiita

サーバー仮想化には、ハイパーバイザー型とコンテナ型がある。
ハイパーバイザー型はVirtualbox。
アプリケーションを実行するためにはまずゲストOSを起動する。
CPUやメモリ、ディスクなどのリソースも多く消費する。

コンテナ型はDocker。
コンテナはホストOSから見ると単一のプロセスとして扱われる。
カーネル部分をホストOSと共有するため、リソース使用量が非常に少ない。

以前どこかのZoomで、サーバ仮想化の技術がどんどん進化しているけど、コンテナ型のDockerは結局、Unixのプロセスと同じだよね、という発言を聞いた時があった。
その時は、そんなものかと特に感動しなかったが、ようやくその意味に気づいた。

コンテナが流行るのは、Infrastructure as codeの流れからして、開発環境やサーバー環境の構築を全てテキストで管理できること。
WindowsでもMacでもAWSでもどこでも同じテキストで構築できる。
そうすれば、作った環境を使い捨てしながらどんどん開発できる。

クラウド時代になって、オンプレミスで物理的なハードディスク装置の冗長化構成などを考える必要がなくなった。
それは単に、物理環境から仮想化環境に変わったことを意味しているわけではない。

一度作った環境は使い捨てにできる。
いつでも同じ環境を復元できるから。
すると、冗長化構成した時も、複数のノードを管理するアプリが重要であって、管理される側のノードはどんどん使い捨てていいというネットワーク設計にすればよい。
かつては、メモリやハードディスク、サーバーは貴重なリソースとして扱う必要があった為に、大切に扱うような設計手法ばかりだったが、今は使い捨てを前提とした設計手法に変わった、ということだろう。

そんな事を考えながら、改めて「ネットワークの根本問題は何だろうか?」を考えている。
ネットワークのQCDをバランス良く実現するためには、現状の技術の制約ではどんな課題があって、どんな設計手法が必要になるのか?
現代のように次から次へと新しい技術が生まれたとしても、その背景にある根本的な問題は変わらないのではないか?と推測している。

たとえば、ネットワークスペシャリスト試験の難易度|ネットワークスペシャリスト.comにこんな一節があった。

(引用開始)
なぜ難易度が高いのか?
これは「午後問題が難しい」ことに尽きます。
また出題範囲が広く、何がどういった形で出題されるかが読めないため対策が立てにくいことも合格を難しくしている要因の1つです。午前試験に関しては過去問の流用が多いので過去問の反復練習で容易に突破できますが、午後問題についてはそうはいきません。
午後試験をいい表した言葉の中で私が印象に残っているのは、「午後試験は、受験者のうち10%未満しか経験したことのない技術についての説明を読み、基礎知識を応用して解く試験である」というものです。
実際に近年だけを見ても、VPFやSDN、VoIP、IPv6、VXLAN、WAN高速化装置、UDP/QUIC、IPsecの詳細など新技術の出題を挙げればきりがありません。
このような問題に対処するためには確かな知識・技能に加え、その応用力が求められます。
(引用終了)

つまり、新しい技術が生まれたとしても、基本的な技術であるOSI7層モデル、ルーティング、スイッチング、TCP、信頼性・効率性・セキュリティなどを理解していれば、問題の本質を見抜けるはずだ。

たとえば、最近のニュースでは、楽天モバイルの普及に苦労している記事を見かける時があるが、基地局まで仮想化してしまおうとする楽天の仮想化技術にはとても興味はある。

楽天が通信網の「完全仮想化」技術をドイツに輸出、目指すはAWSで稼ぐアマゾン | 日経クロステック(xTECH)

楽天モバイルの「世界初、完全仮想化」ネットワーク、分かりやすく説明するとどうなる?:OpenStack Daysでカーン氏が解説 - @IT

CCNAの感想: プログラマの思索

ネットワークの根本問題は何か~昨今のIT技術と時代の変化についての考察: プログラマの思索

Dockerは仮想スイッチと仮想イメージの両方を持つ: プログラマの思索

SDNアーキテクチャの本質は巨大な仮想L3スイッチを実現したことではないか: プログラマの思索

他にも色々考えていく。

| | コメント (0)

2021/10/30

AWSサービスとSW品質特性のマッピングはどうなるか

ふと思いついてメモして、Blogに書くまで昇華できていないアイデアを書き殴っておく。
AWS初心者のロジカルでないメモ。

AWS Fargate とは?「コンテナ」と「仮想マシン」の違い|AWS上のコンテナ関連のサービス | FEnet AWSコラム

AWS Fargateとは?Amazon ECSとの関係性やメリット・デメリットを解説|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本

AWSサービスとSW品質特性のマッピング一覧を作ることで、クラウドが何を解決しようとしているのか、整理したいと思っている。

AWSの最大の恩恵は移植性だろう。OSパッチやセキュリティパッチの作業から基本は解放される意義は大きい。
他にも、障害耐性などの機能性やAutoScalingなどの効率性もあるだろうが、盲点なのは保守性ではないだろうか。

Infrastructure as Codeにより、サーバー構築は全て構成管理の配下に置かれ、保守性を大きく担保する。
しかし、それはアプリケーション層のApacheのhttpd.confの構成管理を意味しているわけではない。
むしろ、AWSがNW機器の物理的実体からデータプレーン、コントロールプレーンという論理的実体へ分離することで、膨大なネットワーク機器を一括管理し構成管理できるようにした点が大きな利点のはず。
AWS上で「データプレーン」を提供しているのは「AWS Fargate」と「Amazon EC2」、AWS上で「コントロールプレーン」を提供しているのは「Amazon ECS」と「Amazon EKS」です、という文言を偶然拾って、ああそういうことなのか!と気づきを得た。
だから、Kubernetesが画期的な技術なわけだ。
CCNAを取得したおかげでこの辺りの意義がなんとなく実感できたから。

インフラ関係のPJをレビューしていていつも思うのは、専用回線の切り替えやDNS切り替えだけのNWリプレースの作業のPJで割と本番障害が多くて、なぜたかがNW機器の入れ替えぐらいでそんなに作業ミスが多いの?といつも思ってた。
DNS切り替えなんて所詮、向き先を変えるだけでしょ、と思ってた。
たぶん、その背後には、数多くのNW機器があり、その設定ファイルを手作業で書き換えて、手作業で検証する必要があって大変なのだろう。
だから、NW層のレベルで構成管理できる意義はとても大きいのだろうと推測している。

| | コメント (0)

2021/08/01

CISOは経営がわかる情報セキュリティ最高責任者である

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドを読んで、CISOは経営がわかる情報セキュリティ最高責任者であると知った。
ラフなメモ。

CISOハンドブック ――業務執行のための情報セキュリティ実践ガイドは、セキュリティの本というよりも、IT技術者が経営層になった時、こういうふうに考えたり行動していくべきで、こういう考え方を持つべき、という点が参考になった。
既存の経営陣に情報セキュリティの重要性を認識してもらうよりも、IT技術者自身が経営の知識を持つ方が手っ取り早いし、その方が実際はうまくいくと思う。

リスク管理は、予想される潜在リスクへの対策だけでなく、想定よりも状況がうまく行った時に備える場合もある。
たとえば、ベンチャー企業が社員20名から200名へ急激に成長した時、事業拡大の速度が速い分、いろいろな歪が出てくる。
上手く行っていたチームも、業務量が増えてメンバーが増えると、チームが回らなくなる。
ソフトウェア開発では人員増はうまくいかないという先入観がありすぎて、人員増を極力抑えるのは失敗しやすい。

事業が予測よりもうまくいくと、問題が少しずつ表面化する。
そこで、こんな対策がある。
業務をアウトソースして、固定費(人件費)費を変動費化する。
商流を変えて、固定費(人件費)を販管費にする。
業務をシステム化して効率化することで、固定費(人件費)を抑制する。

組織的には、事業や業務の観点で組織構造を変えて、チームを分けたり増やしたりする。
チームリーダーを社内で育成する。
それでも不足するなら、リーダーを外部から採用する。

つまり、良い状況に変わることも一つのリスクとみなして、リスク対策は考えるべき。

| | コメント (0)

2021/07/18

IPアドレッシングの計算方法

IPアドレスの計算方法について、理解したことをメモ。
自分のためのラフなメモ。

【参考】

③サブネットマスクとプレフィックス長の2つを覚える ? ランスルネット

④サブネット化したときのホストアドレスと2進数 ? ランスルネット

IPアドレス サブネットマスク・プレフィックス長 早見表 ? ランスルネット

①サブネット化 のメリットの理解 ? ランスルネット

IPアドレッシングを基本から復習しましょ! その16 | ネットワークのおべんきょしませんか?

社内のネットワーク設計でもオンプレ環境でもAWSのVPCのサブネット分割でも、IPアドレスやネットワークアドレス、CIDERの計算は必要。
IPアドレスを計算するには、サブネット早見表を覚えることと同じ。

【サブネットマスク早見表】
1の個数 ビットパターン SubnetMask 【区切り位=NWアドレスの倍数】 サブネット個数
1 10000000 128 128 2
2 11000000 192 64 4
3 11100000 224 32 8
4 11110000 240 16 16
5 11111000 248 8 32
6 11111100 252 4 64
7 11111110 254 2 128
8 11111111 255 1 256

サブネットマスク早見表の覚え方はコツがある。
1bitの個数=8-0bitの個数 ⇒255-2^(0bitの個数)=Subnetmask から計算すればいい。

例:Subnetmask=255.255.255.240 ⇒255-240=15=2^4-1 ⇒8-4=4 ⇒/24+/4=/28
例:/27=24+3 ⇒1bitが3個 ⇒0bitが5個 ⇒255-31=224 ⇒Subnetmask=255.255.255.224

たとえば下記の例題みたいな感じ。

【例題】
192.168.1.0のネットワークアドレスを255.255.255.192でサブネッティングすると、IPアドレスの範囲は何か?

255-192=63 ⇒63=2^6-1 ⇒NWアドレス=64の倍数
サブネットのネットワークアドレスは、第4クオテットが64の倍数になる
サブネットは4個出来上がる
192.168.1.0
192.168.1.64
192.168.1.128
192.168.1.192
⇒ ブロードキャストアドレスは、ネットワークアドレス-1になる。
192.168.1.63
192.168.1.127
192.168.1.191
192.168.1.255
⇒ IPアドレスの範囲は、ネットワークアドレス+1~ブロードキャストアドレス-1になる。
192.168.1.1 ~ 192.168.1.62
192.168.1.65 ~ 192.168.1.126
192.168.1.129 ~ 192.168.1.190
192.168.1.193 ~ 192.168.1.254

【例題】
172.16.0.0のネットワークアドレスを/19のサブネットマスクでサブネッティングしたとき、サブネットのネットワークアドレスは?
IPアドレスの範囲は?

/19=/16+/3
⇒8-3=5
⇒NWアドレス=2^5=32の倍数
⇒ ネットワークアドレスは、第3クオテットが0も含めた32の倍数になる
サブネットは8個できあがる
172.16.0.0
172.16.32.0
172.16.64.0
172.16.96.0
172.16.128.0
172.16.160.0
172.16.192.0
172.16.224.0
⇒ 最初のサブネット172.16.0.0のブロードキャストアドレスは、172.16.32.0-1 より、
172.16.32.0 - 0.0.0.1 = 172.16.31.255
⇒ 最初のサブネットのIPアドレスは、ネットワークアドレス+1~ブロードキャストアドレス-1 より、
172.16.0.1~172.16.31.254
他も同様。

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門」の通り、IPアドレッシングは要件さえケマれば、計算方法は決まっているので、テトリスみたいに決まる。

インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門はインフラエンジニア向けの良本だ: プログラマの思索

Ciscoコマンドで理解したこともリンクしておく。
Linuxコマンドと別物で全く異なるので、理解に時間がかかった。

アクセスリストの設定パターン: プログラマの思索

NATの設定パターン: プログラマの思索

スタティックルートの設定パターン: プログラマの思索

Ciscoのshowコマンド一覧: プログラマの思索

| | コメント (0)

より以前の記事一覧