pikesaku’s blog

個人的な勉強メモです。記載内容について一切の責任は持ちません。

ミューテックスとセマフォ

ミューテックスセマフォはどちらもOS排他制御を実現する機能

セマフォ

https://e-words.jp/w/%E3%82%BB%E3%83%9E%E3%83%95%E3%82%A9.html#:~:text=%E3%82%BB%E3%83%9E%E3%83%95%E3%82%A9%20%E3%80%90semaphore%E3%80%91,%E3%82%92%E8%A1%A8%E3%81%99%E5%80%A4%E3%81%AE%E3%81%93%E3%81%A8%E3%80%82

※以下に記載した"プロセス"は、"スレッド"に読み替え可能。

・共有資源にアクセスできるプロセス数を管理するカウンタ(カウンティングセマフォ
・P操作で1減算、V操作で1加算
・値を10に設定すれば、10個のプロセスが同時にアクセス可能。
・値をゼロに設定すれば、他プロセスは1以上になるまでプロックされる為、ミューテックスと同様にロックとしても利用可能。(バイナリセマフォ
・この動作を複数のプロセスの同期処理(待ち合わせ)にも利用できる。
→待ち合わせ=同時実行される複数プロセス間での処理タイミングの調整

★重要★
 "共有資源"は複数プロセス間でメモリ上で共有される変数等。ファイルではない。
 ・スレッドの場合、スレッド間の共有変数
 ・プロセスの場合、名前付きセマフォ(仮想ファイルシステム上に生成)

セマフォ利用方法

Linuxシステムコール、セマフォの使い方
セマフォにはキーがある。
・複数のプロセス間でキーによって、生成済みのセマフォを特定できる。
セマフォはリスト(集合)で、1つのセマフォの中に複数のセマフォカウンタを定義できる。

上記参考URLのサンプルコードの処理内容
seminit.c
・ftok()関数で任意のファイルから、ftok()関数でセマフォキーを生成
・生成したキーでセマフォを定義。(要素数は1個だけのセマフォ)
semproc.c
・seminit.cで生成したセマフォでロックをかける。成功したら、ユーザー入力を受けてロックを解除。

seminit.cを実行して、1個目のターミナルでsemproc.cを実行するとセマフォでロックがかかる。2個目のターミナルでsemproc.cを実行するとロック取得待ちになる。

★プロセスはOSのセマフォ機能を使うことで、プロセス間でのロックによる同期処理ができる★

コマンドでの動作確認

カウンタ1個のセマフォを生成(ipcmk) & 生成確認(ipcs) & 削除(ipcrm)
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

$ ipcmk -S 1
Semaphore id: 0
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x7890f5a3 0          ec2-user   644        1

$ ipcrm -s 0
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

$
カウンタ10個のセマフォを生成(ipcmk) & 生成確認(ipcs) & 削除(ipcrm)
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

$ ipcmk -S 10
Semaphore id: 1
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0xdec22ed2 1          ec2-user   644        10

$ ipcrm -s 1
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
$

セマフォメモ

OSが動作するために必須の機能ではないよう。

Amazon Linux起動直後にセマフォ利用状況をipcsコマンドで確認しても、一切使われてない。

kernelパラメタでセマフォ制限の設定あり。
# sysctl kernel.sem
kernel.sem = 32000      1024000000      500     32000
#

パラメタの意味は以下URL参照
2.1.1 システムパラメーターのチューニング【Linux】
※上記URLより引用

kernelパラメタのセマフォ制限の確認

システム全体のセマフォ識別子の上限(引数4個目)超え時の動作

# sysctl kernel.sem
kernel.sem = 32000      1024000000      500     32000
# sysctl -w kernel.sem="32000 1024000000 500 2"
kernel.sem = 32000 1024000000 500 2
# ipcmk -S 1
Semaphore id: 1
# ipcmk -S 1
Semaphore id: 2
# ipcmk -S 1
ipcmk: create semaphore failed: No space left on device
# ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x737eced2 1          root       644        1
0x496e3ae4 2          root       644        1
#

セマフォのリスト要素数上限(引数1個目)超え時の動作

# sysctl kernel.sem
kernel.sem = 32000      1024000000      500     32000
# ipcmk -S 32000
Semaphore id: 3
# ipcmk -S 32001
ipcmk: create semaphore failed: Invalid argument
# ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0xb01d3240 3          root       644        32000

#

システム全体のセマフォカウンタ数の上限(引数2個目)超え時の動作

# sysctl -w kernel.sem="32000 32000 500 32000"
kernel.sem = 32000 32000 500 32000
# ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# ipcmk -S 32000
Semaphore id: 4
# ipcmk -S 1
ipcmk: create semaphore failed: No space left on device
#

上記制限はシステム全体の制限。
なので、特定ユーザーが大量消費し制限到達したら、他ユーザーは使えなくなる。
ただし、rootユーザーはセマフォを削除できる。
他ユーザーは別ユーザーのセマフォは削除はできなさそう。

$ id
uid=1001(hoge) gid=1001(hoge) groups=1001(hoge)
$ ipcs -s

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x44564196 5          root       777        1
0x1833097e 6          ec2-user   644        1
0x96432e7c 7          ec2-user   777        1

$ ipcrm -s 5
ipcrm: permission denied for id (5)
$ ipcrm -s 7
ipcrm: permission denied for id (7)
$

参考

同期処理
セマフォによる同期処理

Man page of SEM_OVERVIEW
→名前付きセマフォの説明あり。「2 つのプロセス間で同じ名前のセマフォ に対し操作を行うことができる。」

multiprocessing --- プロセスベースの並列処理 — Python 3.10.6 ドキュメント
threading --- スレッドベースの並列処理 — Python 3.10.6 ドキュメント
→multiprocessingとthreadingどちらにもセマフォ操作のメソッドあり。セマフォはマルチスレッドだけでなく、マルチプロセス間でも利用可能。

プロセスの同期
ミューテックスもプロセス間で利用可能

マルチスレッド・プログラミングの道具箱
ミューテックスセマフォの違い。ロック所有権の概念の有無。※以下引用

aws上限

https://aws.amazon.com/vpc/faqs/?nc1=h_ls

引用ここから
Q. How many VPCs, subnets, Elastic IP addresses, and internet gateways can I create?

You can have:

Five Amazon VPCs per AWS account per region
Two hundred subnets per Amazon VPC
Five Amazon VPC Elastic IP addresses per AWS account per region
One internet gateway per Amazon VPC
See the Amazon VPC user guide for more information on VPC limits.
引用ここまで

EIP5個?
と思いきや上限緩和申請対象だった

https://www.t3a.jp/blog/infrastructure/ip-limited-mitigation/

vpc5個?
と思いきやこちらも
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/amazon-vpc-limits.html

100まで生けるみたい。

aws arp動作について

vpcではarpスプーフィング対策あり。でも完全ではない?どこがだろう。
仮想ネットワークでは、仮想マシンが発行したarpリクエストはネットワークを流れず、仮想ネットワークのデータベースを検索して、arp応答が返されるのだろう。対策完全な気もする。仮想マシンarpリクエストを送ったらとどくのかも。

https://blog.hatena.ne.jp/pikesaku/pikesaku.hatenablog.com/edit?utm_source=admin_touch_myblog&utm_medium=referral&utm_campaign=new_entry

Moreover, while address resolution protocol (ARP) packets trigger an authenticated database look-up, ARP packets never hit the network as they are not needed for discovery of the virtual network topology. This means ARP spoofing is highly improbable on the AWS network. Also, promiscuous mode does not reveal any traffic other than traffic bound to and from the customer operating system. Customers can set precise rules for traffic ingress and egress which allow for increased connectivity flexibility, and enable more customer control over traffic segmentation and routing.

AWS機能の簡易説明

aws firewall manager

awsの以下firewall機能のポリシーを一元管理
 aws waf
 aws sheild advanced
 vpc security group
 
ルールを定義すると、新規にアサインしたリソースに自動適用される。

未適用リソースがないか継続的にモニタリングも可能
 aws firewall manager設定に応じてaws configルールが自動作成される。

aws organizationsと統合されており、複数アカウントにも適用できる。

aws directory service

用途に応じ3種類あり。
aws managed microsoft ad フルスペックad
simple ad linux-samba active directoryによるディレクトリサービス
ad connector 既存adへプロキシ

ia/pwのみ管理すれば良い場合
→simple ad

フルスペックadが必要な場合
aws managed microsoft ad

既存adを利用したい場合
→ad connector

オンプレadと連携する方法は2種類

aws managed microsoft ad
→オンプレadと信頼関係を結ぶ。オンプレとの帯域はケア不要。

ad connector
→オンプレadとプロキシ連携。オンプレとの帯域、オンプレ負荷ケア必要。

awsにおけるad利用パターン
2つあり。
awsで構築するシステムにad必要なパターン
awsを使うユーザーをadで管理するパターン
 awsユーザーの認証をadにオフロード

amazon cognito

webアプリ向けユーザー認証認可サービス
認可対象はawsサービス
例)webアプリで認証したユーザーにs3の特定バケットにアクセス許可する

認証はcognitoユーザープール機能、もしくはFacebook等のパブリックプロバイダ、OIDC/SAMLプロバイダ
認可はcognito idプール機能

ユーザープール機能
フルマネージドなidプロバイダ
ディレクトリサービス

ユーザープロファイル
トークンベースの認証機能 ★何?
サインアップ機能
smsやmfaベースの多要素認証
電話番号やメールアドレスの有効性確認
パスワード変更

lamdaと連携可能。サインアップ前やユーザー認証前後などのトリガーと紐づけ独自処理実装可能

cognito idプール
認証成功したユーザーを認可
一時的認証情報(temporary session
credencial)
※一時認証情報は、amazon security token service(sts)が提供。iam roleと同じ仕組み。

認証フロー
clientがcognitoユーザープールで認証
clientがトークン受領
clientがcognito idプールにトークン渡して権限要求
cognito idプールはトークンの有効性をチェック
cognito idプールはstsに権限要求
stsはcognito idプールに一時的認証情報(temporary session
credencial)を提供
cognito idプールは受領した一時的認証情報をclientに提供

ADメモ

https://blogs.manageengine.jp/structure/

ドメインツリーとは?

ドメインを分けて管理すること
https://blogs.manageengine.jp/wp-content/uploads/2016/04/%E5%9B%B34.png

親子関係だと信頼関係が結ばれる。

信頼関係とは?

信頼関係=信頼先は信頼元のユーザー、グループ情報を管理できる

a.hoge.local
b.hoge.local

親子でなくても信頼関係は構築できる。親子の場合は自動的に結ばれる。

相互に信頼関係を設定することも可能。

https://news.mynavi.jp/techplus/article/techp909/

https://blog.serverworks.co.jp/tech/2017/11/14/active-directory-trust-relationship/
管理だけでなく、認証も可能。

「信頼とは、ドメイン間に確立する関係のことで、これにより、あるドメインのユーザーを他のドメインドメインコントローラーに認証させることができます。」

ドメインツリーとは?(少し深く)

AD前進のNTドメイン時に主に利用された機能。
NTドメインは親子関係作れす、オブジェクト数にも上限あった。上限超える場合は、別ドメイン用意し、信頼関係でゾウキしてた。
ただADはオブジェクト数は無制限。
なので、昨今では用途が限定的らしい。

フォレストとは?

ドメインツリー毎に信頼関係をもたせた状態

推移的信頼関係とは?

フォレスト間で信頼関係を結ぶ場合。
友達の友達は友達の考え。

Direct Connectメモ

参考

パブリック仮想インターフェイスから AWS へのアクティブ/アクティブまたはアクティブ/パッシブ Direct Connect 接続を作成する

上記URLに、Direct Connectの仮想パブリックIFでActive/Actice・Active/Passiveのパス制御について記載あり。
ASNにはパブリックとプライベートがあり、仮想パブリックIFの場合、どちらでも使えるとのこと。

Active/Activeにする場合

ASN種別 設定方法
パブリック 2つのBGPセッション同じプレフィクス情報をアドバタイズする
プライベート 不可

Active/Passiveにする場合

ASN種別 設定方法
パブリック 2つのBGPセッション同じプレフィクス情報をアドバタイズする
AWS→オンプレはAS_Path プリペンドで制御
オンプレ→AWSはLocal Preferenceで制御
プライベート Activeにしたいパスの方で長いプレフィクス情報を流す。
例)Passive側で/24で流してる場合、/25を2つで流す
ロンゲストマッチの仕組みだろう。

ASNがパブリックとプライベートで制御方法が違う。。。
よくわからなくなってきた。。。。
※Skill BuilderのNetworking Specialityの模擬試験にあり。