常連

### 前提・実現したいこと

現在リンク先にあるようなPrivateLinkを用いたクロスアカウントのサービスの連携を構築したいと思い作業しています。
https://qiita.com/mksamba/items/20903940b8b256ef2487

### 発生している問題・エラーメッセージ

PrivateLinkを用いた連携のためNLBを初めて構築している中で、ターゲット先にインターネットゲートウェイがルートに含まれていないサブネットに設置されてる２台のインスタンスへのヘルスチェックがUnhealthyになっていて原因を調べ修正してもなかなか解消されません。

＜状況＞
・リスナーのプロトコル・ポートはTCP・80に設定
・ターゲットグループのプロトコル・ポートはTCP・80に設定
・ヘルスチェックのプロトコル・ポートはTCP・80に設定
※ヘルスチェックを解消するためであれば変更可
```
[Health status] Unhealthy
[Health status details] Health checks failed
```

### 試したこと

・ターゲット先インスタンスのセキュリティグループにてクライアント先のVPC CIDRとNLBヘルスチェック用のサブネットCIDRをポート80で許可（アウトバウンドも同様）
　→Unhealthyのまま変わらず

・検証のため一時的にセキュリティグループを「すべてのトラフィック」を「0.0.0.0/0」で許可
　→Unhealthyのまま変わらず

・インスタンスの中身に問題があることを想定し、検証のため既にALBを使用した構成でHealthyになっている別環境のインスタンスのAMIをコピーしインスタンスを立ち上げターゲットに追加
　→Unhealthyのまま変わらず

・VPC到達可能性アナライザーにてNLBのENIからターゲット先インスタンスのプライベートIPまでを分析し、結果は到達可能だった

・pingをターゲット先インスタンスからNLBのENI宛とDNS名宛に投げたが返ってきませんでした

### 補足情報
NLBで失敗している環境で試しにALB用ターゲットグループを作ってみたがそちらもUnhealthy

### 追記
＞(1)80ポートでチェックしていると言うことはHTTPプロトコルでターゲットにApacheもしくはnginxを入れて起動していると思うのですが、こちらのログはどうなっているのでしょうか
　→Apacheが入っており調査した結果403を返しておりました。エラーログを見るとヘルスチェック用に作成した/var/www/html/index.htmlへのpermission deniedが出力されていました。
出力結果が以下のものです。（一部伏せております）
```
[/var/log/httpd/access_log]
xxx.xxx.xxx.xxx - - [xx/xxx/2021:xx:xx:xx +0900] "GET /index.html HTTP/1.1" 403 199 "-" "ELB-HealthChecker/2.0"
```
```
[/var/log/httpd/error_log]
(13)Permission denied: [client xxx.xxx.xxx.xxx:xxxxx] AH00132: file permissions deny server access: /var/www/html/index.html
```

NLBのヘルスチェックUnhealthy解消方法

EC2にデプロイしたServletにアクセスしようとすると504 Gateway Time-outになります
但しインスタンスを再起動し、ApacheとTomcatを起動した直後はアクセス出来ます
数分置いてアクセスすると上記のエラーが発生するという状態です
インスタンスへのアクセスはELBを介しています

情報が少なくて恐縮ですがご助力頂ければ幸いです
考えられるケースを挙げて下さるだけでもとても助かります

### 環境
Ec2 linux2
Apache Tomcat 9.0.29

AWSのインスタンスにアクセスすると504 Gateway Time-outになる

### 前提・実現したいこと
AWSを利用したアプリケーション開発を学習中の者です。
現在、学習の一環としてSpring（Java11）でECサイトを作っております。

ALB（Application Load Balancer）を利用し、
EC2を2台ぶら下げる構成をしたいと思っております。

こういった複数サーバーの構成で、
例えばユーザーの商品カート情報などをセッションで管理する場合、
ユーザーが複数のサーバーを行ったり来たりしないように設定が必要だと思います。

設定方針として、下記2つのアクションプランを考えたのですが、どちらがベターと考えられますでしょうか？

**案① ロードバランサ―側でパーシステンス方式を設定**
下記のような設定を、ALBのオプションで設定できないかと考えております。
https://milestone-of-se.nesuke.com/sv-advanced/appliance-server/load-balancer/

**案② セッションストアをelasticacheに外出しする**
下記のように、Session情報をRedis等に保存しておいて、各サーバーで参照させる方法もできるのかなと思っております。
https://amg-solution.jp/blog/15219

とりあえず2つほど案を絞り出しましたが、
インフラ・クラウドに関しては特に知識がないという自覚があり、
他にも「こういった方法があるよ」といったものがあれば、ぜひ教えていただけると幸いです。
何卒よろしくお願い致します。

【AWS】複数サーバーをまたがったセッション共有について【Spring】

今まで開発していたアプリケーションを本番用に調整しているのですが、実装方法が良い実装方法が思い付かず相談に乗っていいただけないでしょうか？

## 構成
現在、下記のようなサーバー構成になっています。
ALBがロードバランサーになっており、EC2の冗長化をしています。

![イメージ説明](941da7686e6decfec50add8c7147a593.png)

便宜上、mainとsubと言う名前にしています。

どちらにも同じプログラムが載っています。
また、時限処理を行いますので、それぞれcronを実行しています。

### 処理の内容
メッセージをメールで送るアプリケーションを作っています。  

ユーザーが指定した時間に、cronでメッセージを送信します。 
cronの設定は、laravelで登録したスケジュールを使っています。


## お伺いしたい事
開発しているアプリケーションは時限処理を行なっています。
そのため、複数構成のサーバーに同じアプリケーションを置く場合、それぞれの環境でcronが実行されてしまいます。  

そのため、重複してスケジュールを実行してしまいます。
場合によっては、２重送信される事も考えられます。

この場合、プログラム側、もしくはサーバー側でどのような対策を取るのが良いでしょうか？
まだ構築している最中ですので、サーバーの構成も、プログラムの構成も変える余地はあります。


## 私なりに考えられる方法
数点考え付きますが、それぞれ懸念点があり決めかねています。

### 1. 片方だけ実行できるように調整する
上記の構成で言う、mainインスタンスのプログラムにスケジューラーを設定して、subでは実行しない方法です。
しかし、これではmainが落ちてしまった時に機能しなくなってしまいます。

### 2. スケジューラー用にインスタンスを作る
スケジューラー機能だけのサーバーを立てて、スケジューラを動かします。
上記のようにインスタンス毎の違いが出ないので構成がわかりやすくなります。

ただ、この案もサーバーが落ちてしまうとスケジューラーが機能しません。
また、サーバー代も余分にかかります。

### 3. データベース側で送信ずみのフラグを用意する
スケジュールが２回実行されることは諦めて、送信済みかどうかをフラグで処理するようにします。  
今後サーバーが増える場合、重複した処理が増えることになりますので、パフォーマンスが落ちる可能性もあります。

【Laravel】【AWS】冗長化されたサーバーでのCron処理について

お世話になります。

下記質問に関連しての質問です。
https://teratail.com/questions/45638

moonphase様の回答に
> ELBがクライアントへレスポンスを返す際にSet-Cookie:ヘッダのMAX-AGE値を設定する

とありまして、それに関する質問となります。

#お聞きしたいこと

> ELBがクライアントへレスポンスを返す際にSet-Cookie:ヘッダのMAX-AGE値を設定する

これは「リクエストの度に残存期間（ここでは120秒）が設定され直す」という理解で正しいでしょうか。

つまり、下記の認識が正しいかを気にしております。

- 120秒より小さい間隔でHTTPリクエストを実施していれば、同じバックエンドサーバにルーティングされる
- 120秒間を置いてリクエストすると、前回と違うバックエンドサーバにルーティングされる可能性がある

#背景

ALB(Application Load Balancer)の使用を検討しておりますが、
CLB(Classic Load Balancer)と違い「アプリケーション制御によるセッション維持」が選択できないため、
全体の挙動として問題ないかを懸念しております。

本件でアプリケーション側で生成されるCookieの仕様を詳細に把握できていないのですが、
Webサービスとして「20分間無操作だとログアウトされる」ような挙動であるとのことです。

ここで、上述の質問における私の認識が正しければ、
ALBの[Stickiness duration]を「20分間」に指定すれば問題ないと考えております。

#調べたこと

下記ドキュメントを参照しましたが、今回お聞きしたいことは読み取れませんでした。
（こちらは本筋ではありませんが、「有効期限後に自動的に更新」という意味を理解できておりません）

> スティッキーポリシー設定では、各 Cookie の有効期間を設定する Cookie 期限を定義します。Cookie は有効期限後に自動的に更新されます。

http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/classic/elb-sticky-sessions.html


以上、ご確認いただけますよう、よろしくお願い致します。

ELB生成のセッション維持用Cookieの有効期間の考え方について

**ELB × nginx（リバースproxy） × Nodeサーバーの環境で、Nodeサーバー側のシステムにアクセス元IPアドレスを渡したい。**

**□ 状態（追記しました）**

- リスナー設定

```
TCP(80) -> TCP(80)
SSL(443) -> TCP(80)
```


**□ 今分かっていること**
- ELB × nginxの環境で、$remote_addrがELBのアドレスになる
- ELB側でアクセス元IPアドレスがヘッダーの「X-Forwarded-For」に渡されている
ということは把握しています。
リバースプロキシを使用しない場合は「X-Forwarded-For」からアクセス元IPアドレスはとれました。

ですが、nginxでリバースプロキシを使用する場合は「X-Forwarded-For」にもELBのアドレスが入ってます。
（これはnginx側でセットされたのでしょうか・・・）

**□ nginxの変数**
$remote_addr, $proxy_add_x_forwarded_for にはELBのアドレス
$http_x_forwarded_for は空

何か情報をお持ちの方がいらっしゃいましたら、ご教授願います。
よろしくお願いします。

***

**/etc/nginx/nginx.conf**

```conf:nginx.conf
http {
    include         /etc/nginx/mime.types;
    default_type    application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;


    keepalive_timeout   65;
    types_hash_max_size 2048;

    include /etc/nginx/conf.d/*.conf;
    index   index.html index.htm;

#    set_real_ip_from   10.0.0.0/8;
#    real_ip_header     X-Forwarded-For;

}
```

**/etc/nginx/conf.d/default.conf**
```conf:default.conf
server {                                                             
server {
  listen 80 proxy_protocol;
  server_name hoge.hoge.jp;
  proxy_request_buffering off;

  set_real_ip_from XX.XX.0.0/XX; # VPC CIDR
  real_ip_header   proxy_protocol;

  location /demo/ { # デモページ（html）
    proxy_pass http://demo.localhost/;
  }

  location / { # socket.io用のjsファイルを読み込むのに使用します。
    proxy_pass http://0.0.0.0:1000;
  }

  location /socket.io/ { # websocket通信
    proxy_pass http://0.0.0.0:2000;
    proxy_set_header X-Real-IP $proxy_protocol_addr;
    proxy_read_timeout 150;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Forwarded-For $proxy_protocol_addr;
    proxy_set_header X-Forwarded-Proto http;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

}                                                                 
```

***

**□ 進捗**

**AWSのELBにProxyProtocolを有効にするような設定が必要？**
> 参考
[AWS wiki](http://docs.aws.amazon.com/ja_jp/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html)
[How to configure AWS ELB and Nginx for WebSocket protocol? [closed]](http://stackoverflow.com/questions/33433768/how-to-configure-aws-elb-and-nginx-for-websocket-protocol)
[Using Proxy Protocol With Nginx](https://chrislea.com/2014/03/20/using-proxy-protocol-nginx/)


**＞ProxyProtocolを有効にしました。(追記:2016/02/10 16:28)**
恐らくあと少しで解決しそうです・・・！

TaichiYanagiyaさんの案①を参考に設定すると、nginxのログにはアクセス元IPが出てきました！

```
'$proxy_protocol_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent "$http_referer" ' '"$http_user_agent"';
```

```
 - - [10/Feb/2016:16:15:01 +0900] "PROXY TCP4 [アクセス元IP] XXX.XXX.XXX.XXX 5602 443" 400 172 "-" "-"
```

但し、BadRequestが出ています・・・
もう少し調べてみます・・・！

**＞ProxyProtocolを有効にしました。(追記:2016/02/10 19:21)**

ひとまず、現状の設定ファイルの内容に更新しました。
ProxyProtocolを有効にしたことで、Bad Requestが発生しています。

AWSのProxyProtocol使用の前提条件に「プロキシサーバーとロードバランサーの両方で有効になっていること」とありました。
http://blog.serverworks.co.jp/tech/2013/08/01/elb-proxy-protocol/
Nodeサーバー側でも何らかの処理が必要になるのでしょうか・・・？

その方面で検索すると[こちらの記事](http://blog.serverworks.co.jp/tech/2013/08/01/elb-proxy-protocol/)を発見しましたので、調べてみます。


**＞ProxyProtocolを有効にし、BadRequestは解決。ただ、他のVHと共存できない(追記:2016/02/15 18:04)**

- TCPで通信するVirtualHostのみにした際、BadRequestは解決し、ログファイルにも「"PROXY ..."」ではなく「"GET ..."」という形でログが残るようになっていました

ただ、他にHTTPで通信しているVirtualHost(Server Nameで分けている)が接続できなくなった。

構造は以下の通りになっています。

```
[ELB1]
 server_name hoge.jp
  HTTPS(443) -> HTTP(80)
  HTTP(80)   -> HTTP(80)
  [nginx]
    root(/var/www/html)

[ELB2]
 server_name node.hoge.jp
  SSL(443) -> TCP(80)
  TCP(80)  -> TCP(80)
  [nginx(Reverce Proxy)]
    / -> 3000port(Nodeサーバー)
    /socket.io/ -> 4000port(WSサーバー)

[ELB3]
 server_name main.hoge.jp
  HTTPS(443) -> HTTP(80)
  HTTP(80)   -> HTTP(80)
  [nginx]
    root(/var/www/main)
```

※インスタンスは１つ
※現在、最小構成にしているのでProxyサーバー、Appサーバーなど分けていません。

proxy protocolを有効にすると**ELB1**と**ELB3**が接続できなくなります。
（ELBのヘルスチェックで引っかかる）

TCPとHTTPの共存は厳しいのでしょうか・・・？

ELB配下のEC2でnginxのリバースプロキシを使っている環境のみアクセス元IPが取得できない

表題の件につきまして、VPC-AにデプロイしたALBからVPC-BとVPC-CへHTTP/HTTPS通信を振り分けたいと思っています。

その際のVPC-AとVPC-B、VPC-AとVPC-Cとの接続について、VPCピアリング接続とTransit Gatewayを使用した接続、どちらでも通信は実現可能でしょうか。

ALBをデプロイしたVPC外のIPをターゲットとして指定可能であることは認識しておりますが、接続についてご存知の方にご教授いただけますと幸いです。

VPCをまたいだLB（ALB）を行う際のVPC間接続について

＜ユーザーアクセス側からのアクセス図＞
![イメージ説明](5b21e51804e37fa64d462de73307913d.png)

＜開発側からのアクセス図＞
![イメージ説明](ab5089e127df2540360cf4fc2f8518bf.png)

上の図を元に、インターネット向けのロードバランサーALBを作成した後、説明にある**DNS名（Aレコード）をコピペしてアクセスすれば、**「502 Bad Gateway」のエラーが出るようになるはずなのですが、下の画像のようなエラーが出てしまいます。
※太字の方法でアクセスするという認識でおりますが、この方法で良いのでしょうか？

![イメージ説明](cb1b4ed1fb51af7c3f0d39d1c0814498.jpeg)

主に以下３つの対処を試みましたが、結果は変わらず、途方に暮れております。
502 Bad Gatewayと表示される段階にまで持っていきたいのですが（ターゲット設定は後ほどするため、この状態で問題ありません。）これはやはり作成時の設定に問題があるということなのでしょうか？
何か助言を頂ければ助かります。宜しくお願い致します。


➀ロードバランサー作成段階でリスナーの設定内容がHTTP(80)のみになっているため、アクセス図にあるHTTPS(443)をリスナーの設定に追加しようとしたのですが、証明書が必要になっており、作成では証明書を使用しないことになっているため、HTTP(80)のみで作成しました。

調べてみたところ5XX系や402系？のエラーの対処に関しては載っているのですが、「このサイトにアクセス出来ません」のケースはなかなか見つからずにおります。

➁ALB作成の際に新規作成したセキュリティグループのインバウンドルールにはコマンドプロンプトで出力させたPCのIP３つが記載されているのですが、全てSSH(22)になっていることが問題なのでしょうか？

➂原因調査した際、設定したサブネットがパブリックサブネットでないとアクセスが出来ない。とありましたが、作成済のパブリックサブネット２つを設定していました。
EC2インスタンスも起動しております。

Elastic Load Balancing