CloudFrontのキャッシュヒット率が酷い → 自分の設定が酷かっただけであった

以下の記事で動画配信の仕組みを作成した。
yoneyore.hatenablog.com

動画配信自体は問題なかったが、視聴者が増えるにつれて動画がスムーズに見れないという人が増えてきた。
Chromeのバージョンが上がった事で利用しているVideo.jsをアップデートしないといけないなどはあったが、多分原因は当初から分かっていた。
CloudFrontのキャッシュヒット率である。
ただ、これはどうしようも制御できないと勝手に思い込んでいた。
そのため、たまに再生するなどでカバーするしかないのかと思っていた。
結果、以下の様な酷いキャッシュヒット率をキープしていた。

さすがにVimeoとか利用するしかないかなぁと思いながらも改善方法ないかと思い、CloudFrontのガイドを読み返してみた。
結果、重大な設定が行えてなかった事に気が付いた。。。
キャッシュ生存期間の設定が行えてなかった。。。
docs.aws.amazon.com
1～2時間位の突貫で作成したとはいえ、ちょっと確認不足であった。
そのため、S3 & LambdaからS3オブジェクトに対してちまちまmax-ageの設定を行おうと思い色々施行錯誤していたら、以下の様な記事が…。
dev.classmethod.jp
完全に自身の勉強不足なだけであった。。
AWS側としては、CloudFrontにキャッシュ貯めておいてもそれだけ使ってもらえたら料金ペイ出来るやろし、わざわざキャッシュアウトとかケチ臭いことせんのか(貧乏SEに被害妄想やった…)

Amazon Web Services 定番業務システム14パターン 設計ガイド

P195 Elastic Stack

データ取込:Logsash、Beats
データストア:Elasticsearch
データ可視可:Kibana

データ分析基盤構築入門［Fluentd，Elasticsearch，Kibanaによるログ収集と可視化］

P41 cat API

ElasticsearchのAPIは基本的にJSONでレスポンスを返しますが、cat APIを使うとsshターミナル上でも人が認識しやすい形式で結果を取得可能

ex)
インデックス一覧取得

curl localhost:9200/_cat/indices/ 

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

P79 td-agent

安定版Fluentd、Fluentdを実行するために必要なRubyバイナリ、デーモン化するための起動スクリプト関連の設定ファイルを含んだオールインワンパッケージのこと。
これを利用するメリットとしては、既にRubyなどを使っている環境に影響を与えずに導入できることである。

データ分析基盤構築入門[Fluentd、Elasticsearch、Kibanaによるログ収集と可視化]

Wi-Fi経由でAndroid端末の一部アプリが動かない

事象

無線LANの設定を変更した。
すると、Android端末かつ無線LANのアクセスポイント経由でアクセスが行えなくなった。
但し、一部のアプリは動いていた。

原因1

key更新間隔が0分になっていたため

対応方法

60分などの値に変更する

原因2

IPv6の設定が有効になっていたため

対応方法

Ipv6の設定をOFFにする

発生機器詳細

無線LAN親機

BUFFALO WXR-1900DHP3

アクセスできなかったハード

• Android端末(スマホ)：SHARP R3 SHV44(Android10)
• Android端末(タブレット)：京セラ Qua tab QZ8(Android9)

上記ハードでアクセスできなかったアプリ

• みまもりSwitch
• LINEマンガ
• マガポケ
• docomo bike share service

上記ハードでアクセスはできたが、一部問題があったアプリ

• twitter(閲覧、ツイートはできたが、画像や動画が表示されなかった)
• 楽天マガジン(アクセス、ダウンロード、雑誌閲覧は行えたが、サムネイル表示が行えなかった)

上記ハードなのに、問題なく利用できたアプリ

• 楽天kobo(楽天マガジンではエラーになったが、楽天koboではサムネイル表示は問題なかった)
• Chrome(Chrome経由のtwitterであれば画像閲覧も含め問題なかった)
• LINE(画像など問題なく表示できていた)
• Youtube
• Google Play Music

問題なく利用できていたハード

• Lenovo ThinkPad x395
• Lenovo ThinkPad x1 carbon 2017
• デスクトップPC(有線接続)
• iPhone8
• Nintendo Switch

事象詳細

無線LAN親機の管理者パスワードを忘れてしまい、初期化せざるをえない状況になってしまった。
そのため、初期化を行った後、SSIDの変更などを行い、家にぶらさがっている端末の設定をよなよな行っていた。
結果無事復旧したと思われたのだが、少ししてから異変に気付いた。。
画像を沢山表示するアプリ or 普段アクセスしたら重たいアプリが軒並みアクセスできなくなっていると。。
調査して以下の事が分かった。

• 今までアクセスできていたのに、設定変更でアクセスできなくなった
• Wi-Fiではなく、携帯電波などを経由すれば問題なくアクセスできた
• Android端末だけアクセスできなくて、WindowsやiOS端末ではアクセスできた

そのため、QoS制御やANY接続など色々触っていたので、変更しては確認してなど時間は要したが上記回答を導きだせた。
(なぜWindowsやiOS端末では問題なかったかという答えは導きだせていないが…)

・・・と思っていたら、翌日の朝とかも問題なかったのに、いつのまにかアクセスできなくなっていた。。。 orz
そのため、色々ごにょごにょ触っていたら、Buffaloのルーターに以下の様な設定が存在していた。

このインターネット＠スタートという唐突に出てくる単語は、自動回線判別機能を用いて設定している部分である模様である。
(各社のルーターに思うのが、唐突に意味の分からん単語を書き並べるのを辞めてほしい…。せめてツールチップ位置いて欲しい。)
ここが正確にはきちんと調べていないが、IPv6が変に有効になって通信がうまくいってないように思われる。
この設定をOn/Offを何度か繰り返し試した結果、IPv6を使用しないを設定する事で上記事象が発生しない事が判明した。
また、速度に関しても、何社かの速度判定サービスを用いて複数回アクセス行ったが、平均速度もあまり大差なかったので、現状IPv6が使えなくて困るシーン無いので、当設定はオフにすることにした。
(変にバグとかでIPv6ブリッジ機能が思わぬ動きされても嫌なので…)
詳細な原因追及はIPv6が必要になった際に行うことにし、布団に入る事とした。

パケットキャプチャ無線LAN編(Wiresharkによる解析)

マスタリングTCP/IP IPv6編 第2版

プロフェッショナルIPv6

GiLlabに 502 Whoops と怒られる

事象

gitlabをインストールして、起動させようとすると以下のURLの様なエラー画面が表示される。
エラーメッセージには、「502 - Whoops, GitLab is taking too much time to respond」としか書いておらず、何が原因か分からない。
gitlab.com

結論

原因

pumaのポート番号が、同じサーバーに立ててあるRedmineのUnicornと被ってたため

対応方法

gitlab.rbのpuma['port']のコメントアウトされている箇所を外し、別のポート番号に修正した

#puma['port'] = 8080
puma['port'] = 8079 

調査過程

サーバー/ミドルウェア構成

・AWS EC2 CentOS7
・GitLab 13.0.6(cat version-manifest.txt)
・Apache HTTP Server 2.4.43(nginxは既にApacheが鎮座してたので使わず)
・Redmine with Unicorn 3.3.4 stable

調べた事

上記画面の内容では全く分からないので、ログ置き場(デフォルト /var/log/gitlab)に移動した。
ls -ltrコマンド打ったら、いろいろログが書かれていた。そこで、PUMA(GitlabのAPサーバー)のディレクトリに移動した。
ディレクトリの中にあるcurrentというファイルに直近のログが書かれるみたいなので、ログを眺めていると、"addres already in use"とよく見かける文言を発見した。
調べたところ、同じ筐体で稼働させているRedmineのUnicornが8080を使っており、GitLabのPUMAのデフォルトも8080なので被ったようである。(※1)
なかなか分からなかったのは、redmin.rbのファイル内にpuma['port']やpuma['enable'] がコメントアウトされているので、デフォルト値が採用されているというのが気付くのが遅れてしまった。

※1
なお、GitLabは以前はUnicornで稼働していたが、現在のバージョンではPUMAがデフォルトのようである。

最終的に修正した箇所

(gitlab.rb)

external_url 'https://www.yoneyore.jp/gitlab' #httpsにする、gitlabのホームURLを指定

gitlab_rails['time_zone'] = 'Asia/Tokyo' #必要に応じて設定

gitlab_workhorse['listen_network'] = "tcp" #Apacheを経由する場合必要
gitlab_workhorse['listen_umask'] = 000
gitlab_workhorse['listen_addr'] = "127.0.0.1:8081" #フロント(gitlab_workhorse)側のポート番号

nginx['enable'] = false # Apache使う場合は変更必要

puma['enable'] = true #コメントアウトしててもデフォルト起動するが、それでは分かりにくいので宣言しておく
puma['port'] = 8079 #ここが今回の修正の肝

(conf.d/gitlab.conf)

 <Location /gitlab>
    Require all granted

    ProxyPassReverse http://127.0.0.1:8081
    ProxyPassReverse http://www.yoneyore.jp/gitlab

    RequestHeader set X-Forwarded-Proto 'https'
    RequestHeader set X-Forwarded-Ssl 'on'

#正直、以下の定義が必要なのかどうかよく理解できていない。。。
    RewriteEngine on
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
    RewriteCond %{REQUEST_URI} ^/uploads/.*
    RewriteRule .* http://127.0.0.1:8081%{REQUEST_URI} [P,QSA,NE]
</Location>

最終的なアクセス経路

ブラウザ→
443:https→
443:Apache HTTP Server→
8081:http→
8081:Gitlab[gitlab_workhorse]→
8079:http→
8079:Gitlab[PUMA]

GitLab実践ガイド impress top gearシリーズ

インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現

共有ディスクにアクセスするとSMB1プロトコルが必要ですと怒られる

【事象】
BUFFALOの無線LANWXR-1900DHP3に対して、USBディスクを連結させた。
そして共有ディスクにアクセスするため、\\192.168.11.1という値を入力した。
結果、

安全でないためファイル共有には接続できません。この共有には最新でない SMB1 プロトコルが必要です。

というエラーが発生する。(See. エラー内容詳細)

エラー内容詳細

【原因】
SMB1.0がWindowsから削除されていたため

【確認方法】
[コントロールパネル] - [プログラムと機能] - [Windows機能の有効化または無効化] を開く。
その一覧から、SMB 1.0/CIFSファイル共有のサポートのSMB 1.0/CIFSファイル共有のサポートという箇所にチェックボックスが入っているかを確認する。
なお、Windows10だからかどうか分からないが、当チェックボックスの設定有無はsc.exe qc lanmanworkstationを実行しても確認できなかった(このチェックボックスが入っている/いないに関わらず、DEPENDENCIES欄にMRxSmb10が表示されていなかった)。

【対応方法】
上記チェックボックスを有効化し、Windowsを再起動するとアクセスできる様になった。
但し、SMB1.0は重大な脆弱性が発見されているプロトコルのため、極力利用するのは控えるのが好ましい。
そのため、共有ディスクサーバー側でSMB2以降のプロトコルに対応してもらうのが正攻法である。

【参考リンク】
www.buffalo.jp
www.nedia.ne.jp

Logitec 外付けHDD 外付けハードディスク USB3.1 Gen1（USB3.0） 3TB LHD-ENA030U3WS

(超静か、コンパクト、見た目や素材がカッコいい、縦・横でどちら置きにも対応、3TBで1万円以内で安い、安心の日本製と超お勧め)