zuntan02のはてなブログ

備忘録的なものです

ニンテンドースイッチのジョイコンのスティック交換メモ

【問題】

ゲーム中にスティックが一方向に入り続ける状態になった。

【確認】

[HOMEメニュー]-[設定]-[コントローラーとセンサー]-[スティックの補正]
で左右のコントローラのスティックを確認してみたところ、右側のコントローラのスティックが下に入り続けている模様

【交換】

■交換部品の注文

今回は
Switch NS Joy-con対応 Joy-Con for Switch コントロール 右/左 センサーアナログジョイスティック 交換用 2個 キャップ付き
を注文した。2日後に到着(ヘタに安いやつを注文すると届くまでに数週間とかかかってしまうらしいので……)。

■分解と交換

★注意★
分解には任天堂の機器ではおなじみのY字ドライバーが必要です。持ってなければ
このへんを買っておけばベター。

1)コントローラの外装はY字ドライバでネジを外して、背面を開けます。
2)バッテリーは両面テープで止まってるのでぺりっと剥がしておきます(ケーブルを抜く必要はないです)
3)バッテリーの乗っていた台のネジ(上下3個)を、+の精密ドライバで外して台を横によけると、問題のスティックが見えてきます
4)スティックを止めているネジ(2個)を+の精密ドライバで外す
5)スティックのフレキシブルケーブルが刺さっているコネクタの、ケーブル挿入口の反対側に灰色の押さえがあるので、これを上に持ち上げでケーブルをそっと抜く
6)スティックを新しいものに交換、フレキシブルケーブルを差し込んで、先ほど持ち上げた押さえを戻してケーブルをロックする
7)バッテリーの台を戻し、バッテリーも元の位置に戻して、ケーブル類を元の位置に戻して、外装も元に戻します。
8)再度[スティックの補正]で、スティックが正常に動作することを確認します

以上。
作業時間5~10分くらい。

【AWS】請求額をプロジェクトごとに確認したい

【手順】

1)ユーザ定義タグをリソースに関連付ける

今回は既に以下のリソースタグが設定されている前提

  • Environment
  • Project
2)コスト配分レポートを配置するためにS3バケットを用意

EC2ダッシュボード-[S3]-[バケットを作成する]、あとは初期値のまま作成
バケットポリシーについては後ほど設定します

3)コスト配分タグの設定

[請求ダッシュボード]-[コスト配分タグ]

  • AWS 生成コスト配分タグを[有効化]
  • ユーザー定義のコスト配分タグで配分したいタグを指定
4)S3バケットポリシーの設定と請求レポート有効化

[請求ダッシュボード]-[設定]
→[請求レポートを受け取る]をチェックし、[S3 バケットに保存]に、上記で用意したバケット名を入れ、[検証]
→エラーになったらメッセージのリンクにあるサンプルポリシーを[アクセス権限]の[バケットポリシー]にコピペでOK

以上

php-opcacheの効果が絶大だったメモ

【概要】

Wordpress(nginx+php-fpm)で、アクセス集中時にCPU負荷がボトルネックとなっていたためphp-OPcacheを導入したところ劇的に改善したのでメモ

OPCacheについては以下を参照
OPcacheを利用してPHPを高速にしよう | WEB ARCH LABO
OPcache導入してみた!(速さ検証もあるよ!) - Qiita
PHPのキャッシュ機構のおさらいと、opcacheの設定とかキャッシュクリアとか - waste of time

上記からのぼんやりした認識

  • コンパイルされたバイナリコードをメモリに置いておくので、同じようなリクエストが大量に来る場合に効果があると思われる。
  • 実行結果をキャッシュするわけではないので処理には影響でない。

【環境】

OS:Amazon Linux
EC2インスタンスタイプ:m4.xlarge(4Core/16GiB)
Webサーバ:nginx/1.8.1
PHP:PHP 5.6.38

【やったこと】

■パッケージのインストールと初期設定

# インストール

yum install php-opchache

# パラメータ値を変更
php.netの示す推奨値を利用した)
※推奨設定値:http://php.net/manual/ja/opcache.installation.php
 オプションの詳細:http://php.net/manual/ja/opcache.configuration.php

cat /etc/php.d/10-opcache.ini | egrep -v '^(#|$|;)'

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.blacklist_filename=/etc/php-5.6.d/opcache*.blacklist


# サービス再起動して反映

service php-fpm restart
service nginx restart

# 組み込み状態確認

php -v
PHP 5.6.38 (cli) (built: Oct 16 2018 23:34:40)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

php -i | grep opcache
(省略)
負荷確認

f:id:zuntan02:20190109122212p:plain
目に見えてレスポンスが軽くなった。
php-fpmのプロセス数も減少している。
空きメモリの減少も見られない(opcache.memory_consumptionの値が上限と思われる)

もっと早くやっとけばよかった。。。

【Route53+CloudFront+S3+ACM】転送設定:http(s)://hoge.jp/をhttps://sub.hoge.jpにリダイレクト

【作業メモ】

1)Amazon S3 コンソールで、hoge.jp(転送元) の正確な名前を使用して S3 バケットを作成します。

ドメイン名外は全てデフォルトで作成

2)作成したバケットを選択し、[プロパティ] -[Static website hosting]

[リクエストをリダイレクトする]
ターゲットバケットまたはドメイン:sub.hoge.jp
プロトコルhttps

3)Route 53 コンソールで、Aliasにhoge.jp のホストゾーンを選択します。

以下の様に設定

Name:hoge.jp
Type:A
Alias:s3-website-ap-northeast-1.amazonaws.com
Routing Policy:Simple
Evaluate Target Health:No
4)確認

http://hoge.jp → https://sub.hoge.jp
http://hoge.jp/aaa → https://sub.hoge.jp/aaa

★注意★
このままでは、http://hoge.jp(非SSL)からのリダイレクトは対応できてますが、https://hoge.jp(SSL)からはリダイレクトされません。
SSL側も対応する場合は引き続き下記の作業を実施

5)Certificate Managerで証明書を作る

[Certificate Manager]→「hoge.jp」の証明書を取得しておきます(手順は汎用的なものなので省略)

6)CloudFrontのDistributionを新しく作りOriginをS3にし証明書を設定します

[CloudFront]-[Create Distribution]-[GetStarted]

[Origin Domain Name]
→先ほどのS3の設定の時に出てきた{バケット名}.s3-website-{リージョン名}.amazonaws.comを指定します。
(サジェストで出るバケットは指定しちゃダメ)
hoge.jp.s3-website-ap-northeast-1.amazonaws.com

[Alternate Domain Names(CNAMEs)]
hoge.jp(自分のリダイレクト元にしたいドメイン名を指定)

[SSL Certificate]
→Custom SSL Certificateで先ほどのACMhoge.jp)を指定

後はすべてDefaultでCreate

7)Route53でCloudFrontに向くようにRecordを追加する

Alias:s3-website-ap-northeast-1.amazonaws.com

Alias:XXXXXXXXXXXXXX.cloudfront.net

【AWS】Wordpress冗長化をALBとEFSだけでやってみたら遅すぎて無理だったけどCloudFrontとOPcacheでなんとかなったログ

【概要】

EFSが東京に来た時、Wordpress冗長化の決定打では!?とか思ってたんだけど、事例が全然出てこない。遅い…遅い…という怨嗟の声は聞こえたりするので実際にどれくらい遅いのかやってみたら画像が「ぱら・・・ぱら・・ぱ・・・(止まる」みたいな感じでホントに遅かった。CloudFrontで静的ファイルをキャッシュしてみたけど、WordpressだとまずPHPそのものの処理が重い。
対策として静的ファイルをCloudFrontで、phpはOPCacheでさばくことでEBS単体の時と遜色ない性能となった。

【参考】

https://hacknote.jp/archives/38521/
ランダムリードがEBS汎用SSDで18MB/sのところ、EFSは108 KB/sとのこと。なるほどそんな感じだった。

https://postd.cc/wordpress-on-aws-smooth-and-pain-free/
EFSとOPcacheとCloudFrontを利用した解決。これがおそらく現状の正答。

【OPcache有無での差異テスト】

1)全部EBS+CloudFrontで画像およびcss/jsをキャッシュ
2)EFSにWordpress全部入り+CloudFrontで画像およびcss/jsをキャッシュ
3)EFSにWordpress全部入り+CloudFrontで画像およびcss/jsをキャッシュ、にPHPをOPcacheでキャッシュを追加

種別 PageSpeed InsightsのTTFB(※)値
1)EBS+CF 0.18s
2)EFS+CF 7.46s
3)EFS+CF+OPcache 0.33s

※TTFB:Time To First Byte、最初の1バイトが到着するまでの時間

という訳で、WordpressをEFSに全部突っ込んで冗長化しても性能が……という向きにはOPcache+CloudFrontで。

構築メモ

【参考】
https://www.sodo-shed.com/archives/12629
→東京リージョンで使えるようになったAmazon EFSを使って手軽なWordPress冗長化

https://docs.aws.amazon.com/ja_jp/efs/latest/ug/mount-fs-auto-mount-onreboot.html
Amazon EFS ファイルシステムの自動マウント

https://hacknote.jp/archives/38406/
→キャッシュヒット率を上げつつ管理画面に影響を出さない

1) EFS用のSecurityGroupを作成する
[EC2]-[セキュリティグループ]-[セキュリティグループの作成]
→VPCからのアクセスのみすべて許可
2) EFSを作成する
[EFS]-[ファイルシステム]-[ファイルシステムの作成]
ステップ 1: ファイルシステムアクセスの設定
→VPCとマウントターゲットを指定

ステップ 2: オプション設定の構成
パフォーマンスモードの選択:汎用
スループットモードの選択:バースト★
暗号化の有効化:チェック無し

★注意★
BackWPupでデイリーバックアップしてたらEFSのバーストクレジットが枯渇してベースライン(50KB/秒)になって499多発を招いたので、環境作ってからしばらくはCloudWatchのBurstCreditBalanceを見守ることをお勧めします!以下のようにバランスしていない場合場合は諦めてプロビジョンドスループット(10MB/秒で$76)とかにしましょう。自戒を込めて……
f:id:zuntan02:20181229104437p:plain

3)マウント
# マウントポイント作成
mkdir /srv/hoge

# マウント実行
mount -t efs <EFSのファイルシステムID>:/ /srv/hoge

# 再起動後のマウント対応
vi /etc/fstab
# 以下を追記
------------------------------
<EFSのファイルシステムID>:/ /srv/hoge efs defaults,_netdev 0 0
------------------------------

上記のマウントポイントにWordpressを配置、インストールします(通常の作業なので省略)

4)OPCache導入と有効化(以下はnginxの例)
yum -y install php-opcache
systemctl restart php-fpm
systemctl restart nginx
5)CloudFrontで静的ファイル(画像/js/css)キャッシュ対応
[CloudFront]-[Behaviors]-[Create Behavior]

# 以下のパスパターンについてキャッシュを有効化
Path Pattern:*.jpg
Path Pattern:*.png
Path Pattern:*.css
Path Pattern:*.js

# Behavior設定
Origin:ELB
Viewer Protocol Policy:Redirect HTTP to HTTPS
Allowed HTTP Methods:[GET, HEAD]
Cache Based on Selected Request Headers:Whitelist

Whitelist Headers
=====
Authorization	# 管理画面にベーシック認証を入れる時などに必要です。
CloudFront-Forwarded-Proto	# Origin側へプロトコルを通知します。
Host	# Origin側へアクセス先ホスト名を通知します。
=====

Object Caching:Customize
	Minimum TTL:0
	Maximum TTL:31536000	デフォルト1年 ※要調整
	Default TTL:86400		デフォルト1日 ※要調整

Forward Cookies:Whitelist

Whitelist Cookies:(管理画面では画像キャッシュさせない)
	wordpress_logged_in*
	wp-settings*

Query String Forwarding and Caching:None(Improves Caching)

以下デフォルトのままで[Create]
6)CloudFrontで残りのファイルはキャッシュしない対応(Behaviorルールの下端)
[Behaviors]-[Create Behavior]

パスパターン:Defaultについてキャッシュを無効化(TTLを0にするパス、条件を追加)
Path Pattern:Default (*)

# Behavior設定
Origin:ELB
Viewer Protocol Policy:HTTP and HTTPS
Allowed HTTP Methods:[GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE]
Cache Based on Selected Request Headers:Whitelist

Whitelist Headers
=====
Authorization
CloudFront-Forwarded-Proto
Host
=====

Object Caching:Customize
	Minimum TTL:0
	Maximum TTL:0
	Default TTL:0

Forward Cookies:All
Query String Forwarding and Caching:Forward all, cache based on all

以下デフォルトのままで[Create]

f:id:zuntan02:20181211194820p:plain

※その他簡単な検証
丁度Wordpressの4→5化の時期だったので、この構成でWPを4→5に上げたが、特に問題なく終了した。

既存のAWS CodeCommitに接続するアカウントを追加で作成したメモ

【サマリ】

既に存在するAWS CodeCommitリポジトリにIAMアカウントベースで接続する。
(筆者はCodeCommitはおろかGitにも明るくないので誤りがあるかもしれませんが何かの足しになれば)

【作業メモ】

gitのURLをhttpsでやるかsshでやるかで方法が異なります。

HTTPS

手順

1)マネージドコンソールより利用者のIAMを作成(共通)
2)マネージドコンソールより[IAM]-[ユーザー]-対象のIAM詳細-[認証情報]を選択(共通)
3)[AWS CodeCommit の HTTPS Git 認証情報] で、[生成] を選択します。
→CodeCommitにHTTPS接続する際のBasic認証情報が生成されるので保存・連絡

※CentOS6などでgit cloneする場合、basic認証が通らずエラーとなるため、AWS CLI認証情報ヘルパー(未検証)を用いるか、或いは以下のようにして自動的にbasic認証をパスしてみてください

vi ~/.netrc

machine git-codecommit.ap-northeast-1.amazonaws.com
login 認証ID
password 認証パスコード

AWS CLI認証情報ヘルパー
https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-https-unixes.html

SSH

手順

1)利用者はあらかじめ

cd ~/.ssh
~/.ssh$ ssh-keygen -t rsa -b 2048 -f codecommit

の様にして鍵ファイルを生成し、公開鍵(上記のコマンドであればcodecommit.pub)を確認します
2)マネージドコンソールより利用者のIAMを作成(共通)
3)マネージドコンソールより[IAM]-[ユーザー]-対象のIAM詳細-[認証情報]を選択(共通)
4)「AWS CodeCommit の SSH キー」で公開鍵の中身を貼り付ける
 →成功すると「SSHキーID]が発行されるのでこれを連絡
5)利用者は以下のようにしてsshのConfigを設定し、git clone可能となる
vi ~/.ssh/config

Host git-codecommit.*.amazonaws.com
  User APK*****************
  IdentityFile ~/.ssh/codecommit(秘密鍵名)

Windows10でHostsFileManagerを利用する(.Net Framework 3.5の導入)

【概要】

WindowsPCでhosts書き換えを行いながら現行サイト・構築中のサイトを比較していると結構手間。特にPCに詳しくないお客様はhosts切り替えの説明だけで結構な時間を取ることがある。
(過去にこんな記事も書いた)
これまでもお客様にhosts書き換えを依頼するときに、定番のツール
Hosts File Manager
を紹介してきた(※)が、Win10での導入に当たって.NET Framework 3.5が必要だったため下記のメモを残す
※ブラウザのHosts書き換えプラグインも試してみたけど権限の問題でhostsファイルが書き換えられないことが多くてダメ。

【導入手順】

1)ダウンロード

Vector
https://www.vector.co.jp/soft/winnt/net/se406523.html
よりHFM_2.00_x86_ja.zipをダウンロード

2)インストール

HFM_2.00_x86_ja.zip を展開し、Setup.exeをダブルクリックしてインストール
→「.NET frameworkの3.5を必要とします」と出る場合は
Windows 8、Windows 8.1、および Windows 10 への .NET Framework 3.5 のインストール | Microsoft Docs
より

キーボードの Windows キー Windows ロゴ を押し、「Windows の機能」と入力して、Enter キーを押します。 [Windows 機能の有効化または無効化] ダイアログ ボックスが表示されます。
[.NET Framework 3.5 (.NET 2.0 および 3.0 を含む)] チェック ボックスをオンにして [OK] を選択し、メッセージが表示された場合はコンピューターを再起動します。

を実施して有効化。

3)起動

[スタート]-[Hosts File Manager]-[Hosts File Manager]で起動
※UI自体は非常にシンプルなので迷うことはないかと思います。

■詳細な利用手順はこちら

beyondjapan.com