再頒布可能パッケージとは何なのか知りたい
まえがき
VC15, VC16 について調べていたところ、再頒布可能パッケージという用語が出てきた。
今まで何も知らずに使っていたなということで調べた。
再頒布可能パッケージ
Microsoft Visual Studio C++ で開発されたアプリケーションを、 Visual Studio なしに、コンピュータ上で実行できるようにするライブラリ。
x86 と x64 のバージョンがある。
今は一つインストールするだけで、 2015/2017/2019 のすべてのランタイムが一括インストールされる便利なものがあるらしい。
NSClient++
NSClient++ は、 Windows Visual Studio 上で開発されていると考えられる。
GitHub - mickem/nscp: NSClient++
やはりそのようだ。エントリーポイントは以下のファイルみたい。
Windows Visual Studio 上で開発、ビルドされているために、 exe ファイルとして提供されているアプリケーションを利用するためには前提として、再頒布可能パッケージのインストールが必要となる。
Windows の VC15, VC16 っていうのが何か知りたい
VC
「Microsoft Visual C++」のこと。頭文字をとって VC と呼ばれるそうだ。
基本的に Visual Studio で開発されるアプリケーションのよう。つまり、 VC15, VC16 はそれぞれのバージョンの Visual Studio 上でビルドされたアプリケーションということ。
Visual Studio 2019 version 16.0 Release Notes | Microsoft Learn
Visual Studio 2019 version 16.0 とかあるので、おそらく 16 はこの 16だろうと思う。
きっかけ
Windows 版の PHP (zip ファイル形式で提供されているもの) のインストール作業を行っていたところ、 zip ファイルにそれぞれ VC14, VC15, VC16 というバリエーションがあることがわかった。
また、拡張ファイルも同様に、VC14, VC15, VC16 というバリエーションがあり、ここを一致させないとうまく拡張ファイルが読み込まれなかったりした。
この「VC15、VC16」などが何なのか気になったので調べた。
朝寝坊しないようにアラームを設定したい
今、面白いことをしている。
アラームに、「今日はシチューを作る必要があります」と書いておく。
こんな感じ。
すると、寝ぼけなまこで目覚めたときに「あ、今日寝過ごしたら朝飯作る時間なくなって、適当に済ませて会社行かないといけなくなるな」と思って、「起きよう」という気持ちになる。
前提として、朝は毎日食事を作っている。寝坊して時間がないときは晩御飯として買い置きしているコーンフレークを食べたり、コンビニでおにぎりを買って会社で食べたりするのだけれど、これをすると非常に虚しく、悲しい気分になる。
「今日はシチューを作る必要があります」というアラームの名前が寝起きの自分にそれを思い出させることによって、「起きよう」という意思を得ることができる。
スループットと IOPS
前書き
AWS EC2 の EBS について学んでいたところ、ストレージのタイプにおいて「スループット」、「IOPS」という用語が出てきた。
前から両者の違いがあいまいなままにしていたので、この機会にしっかりと調べてみた。
スループット (Throughput)
単位時間当たりのデータ転送量、もしくは処理能力のことである。
データが、どれだけの量、そのデバイスを通過できるのかを表現するものと考えればいい。
CPU 然り、ディスクの I/O 然り、メモリの I/O 然りである。
データ転送量なので、ディスクなどにおいては 2.4GB/s などで表現される。
CPU などにおいては、クロック周波数などで表現される。
IOPS (Input / Output Per Second)
単位時間当たりの読み込み、書き込みの回数を表す。
シーケンシャルアクセスによって測定した場合と、ランダムアクセスによって測定した場合で大きく結果が変化するため、条件を揃えて実施した結果が比較される。
例として、 4KB ランダムライトIOPS などが挙げられる。 4KB のデータをランダムに書き込んだ際の IOPS の値であり、これが比較可能な指標として用いられる。
HDD と SDD の性能差
IOPS
ディスクを物理的にシークする HDD と、電気的に処理している SDD では、圧倒的に SDD の方が IOPS の値はよい。
一般に、HDD よりも SSD の方がこの値は優れるといえる。
スループット
一方で、断片化が発生しているようなことがなく、データにシーケンシャルにアクセスできれば HDD も理論値が出るはずであるであり、この場合においてスループットについては、 HDD と SDD の性能に大差がない場合が考えられる。
一概に、SDD の方が HDD よりもスループットがいいとは言えない。
Ref
紙のノートにまとめたやつ。
2022-11-25 スループット、IOPS ノート 20221125180416412.pdf - Google Drive
PHP と Python の比較
前書き
最近、 Python をよく使うようになった。
PHP との違いについて書く。
環境構築が楽
PHP に比べて、圧倒的に環境構築が楽である。
それも特に、 Windows での環境構築が楽なのが非常に助かっている。
「エコシステムが整っている」というらしい。
プリインストールされている
まず、 Linux ディストリビューションにおいても、 Windows においても、 Python はプリインストールされており、特に何をするでもなく Python は利用できる。
パッケージや dll のインストールがいらない。
PHP のパッケージを使う際、 Linux では so ファイル、 Windows では dll ファイルの設置が必要である。
Linux においては apt や dnf などでインストールできるパッケージが用意されていることが多いので多少簡単だが、 Windows では dll をインストールする必要があり、これが非常に面倒くさい。
Python は pip コマンドで対象のライブラリをインストールするだけでよく、非常に環境構築が楽である。
デバッグの設定が楽
PHP でデバッグを行うためには XDebug のセットアップが必要だが、これが結構難易度が高く、詰まるところが多い。
特に、 Windows 環境においては顕著である。最近ようやくローカルでデバッグできるようになった。
Python では、特に何を設定するでもなく、PyCharm でブレークポイントを設定してデバッグ実行すると「バチッ」とコード実行が止まり、デバッグすることができたので感動した。
オブジェクトの考え方が徹底されている
PHP ではプリミティブ扱いの文字列 (String) などがオブジェクト扱いであり、メソッドを生やして処理を行うことができる。
これにより、コードの書き味が異なる感じがする。
Ruby などもそうだが、個人的にこのようにオブジェクトの考え方が徹底されている言語設計の方が好みである。
多機能ではない印象
PHP は最近のバージョンで便利な記法が増えているが、 Python でやろうとするとできない印象 (Constructor property promotion など)。
他、関数についても PHP の方が豊富だなという印象がする。
Python は仕様変更が PHP に比べゆっくりで、安定している印象。
そのために、機能追加は比較的ゆっくりなのかもしれない。
2022-11-19 AWS SAA-C03
AWS Solution Architect Associate (SAA) の更新をしないといけないため、学び直しを行った。
概要
合格点
720点
配点
100 ~ 1000点
セクション
セキュアなアーキテクチャの設計
ここでは、システムがセキュアになることを目的とする。
そのようなシステムを実現できるセキュアなアーキテクチャの設計となるよう、サービスを選定や設定を行う。
アクセス制限を行うようシステムを構成しましょう。
- IAM のベストプラクティスに従ったアクセス許認可を設計しましょう。
- プライベートサブネット構成によるネットワークアクセスの制限
- (関連) VPN、NAT、ルーティング
- インスタンスへのネットワークアクセス許認可
- (関連) Security Group、ネットワーク ACL
データは暗号化するようシステムを構成しましょう。
- S3 のオブジェクトの暗号化 (暗号化オプション)
- KMS 管理の秘密鍵を利用した暗号化 (S3 のオブジェクト、 EC2 のボリュームなど)
弾力性に優れたアーキテクチャの設計
ここでは、スケーリング等の弾力性に優れたアーキテクチャの設計となるよう、サービスを選定する。
また、耐障害性のような信頼性についても意識して利用するサービスの選定を行う。
適切なストレージを選定しましょう。
多層アーキテクチャの構成で、システムを構成しましょう。
例として、ストレージ層であれば
- インスタンスの停止なしに容量の増減を行うことのできる EFS
- そもそもスケーリングの必要のない S3
例として、アプリケーション層であれば
- ELB
- SQS
- Auto Scaling
- Lambda
例として、DB 層であれば
- RDS
なぜ信頼性・弾力性に優れたアーキテクチャ？
「あらゆるものは、必ず壊れる」ため。
高性能アーキテクチャの設計
適切なストレージを選定しましょう。
- EBS の選定においては、 IOPS やスループット性能を意識する
適切なデータベースを選定しましょう
- RDS
- DynamoDB
- RedShift
キャッシュを利用する形でシステムを構成しましょう
- CloudFront
- ElastiCache
スケーリングする形でシステムを構成しましょう。
- CloudWatch + Auto Scaling + ELB による構成等
コストを最適化したアーキテクチャの設計
課金体系に照らして最適な形でシステムを構成しましょう。
- リザーブドインスタンスを利用しましょう。
- 利用のない EBS ボリュームは削除しましょう。
- S3 の転送量を減らすために CloudFront のキャッシュを利用しましょう。
- CPU の遊休時間を減らしましょう。
人の手のかからない形で、システムを構成しましょう。
- 冗長化やスケーリングによって、障害が発生しにくい構成
- 環境作成・設定変更の自動化、省力化
関連サービス
