Macに変えてLinux計画進行中。早速久々に溜まったセキュリティアップデートを行うが、それを実行中にブラウザは矯正再起動かかるは、日本語IMEがONにできなくなるなど嫌な予感。
しかし何はともあれトラブったときは再起動というわけで、再起動してみたら無事使えた。というわけでアップデートを実施するときは何らかのトラブルがあるという想定で心の準備はしておいたほうが良いというお話でした。
Macに変えてLinux計画進行中。早速久々に溜まったセキュリティアップデートを行うが、それを実行中にブラウザは矯正再起動かかるは、日本語IMEがONにできなくなるなど嫌な予感。
しかし何はともあれトラブったときは再起動というわけで、再起動してみたら無事使えた。というわけでアップデートを実施するときは何らかのトラブルがあるという想定で心の準備はしておいたほうが良いというお話でした。
Macは高い!MacBookProとなれば20万オーバーでWindowsPCではその半額ですら出すことは稀なのに!
そのMacだがここ2年ほど仕事でも使うようになったので必然的に家庭でも利用するようになって、欠かせなくなったのだがなんとディスプレイに縦のラインが微妙に映るようになった。最初はOSの不具合とかの情報もあったのでアップデートすればよいかと思っていたが、2−3日後に今度はちらついて画面を見ていられない状況になる現象が発生。
Appleの公式ルートで修理に出すと10万ぐらい取られそうなのでどうしようか検討中。一番いいのはこんなに金がかかっているのに壊れてしまうMacをやめることなのだ!
というわけで今はUbuntuをLet’s note CF-SX1に入れてメインとして利用している。これは10年近く前のPCだが軽いことしかやってないので全然OKという。脱Mac計画進行中である。
一円で取得したドメインなので使い捨て&実験用途である。
本当に必要であればこちらから手続きするのだが、まー脅しのメールやハガキまできてしつこいこと。更新する気があっても失せるというものだ。
たかだ1円ドメインの更新にそんなにコスト使うの?って感じで費用対効果が全くわかっていない会社だなと思った。
CloudFrontとS3の連携はよく使われるパターンであるが、今回は構築直後のみ発生したトラブル。
CloudFrontからS3へのアクセスはOrigin Access Identityを利用していて、S3のURLを直接打ち込んでもエラー403となるようにしてある。
CloudFrontからアクセスすると、一瞬CloudFrontのURLなのだが、403。よくよくみるとS3のURLにリダイレクトされている。
調べてみると、これはCloudFrontがグローバルなのに対し、S3は東京リージョンにあるため、そのS3 Bucketの認識までに時間がかかるため307でリダイレクトしているらしい。
対応方法は2つあって、24時間程度待つ。
またはS3のURLをリージョン込みのものにするということ。
バケット名.s3.amazonaws.comではなくて、
バケット名.s3-ap-northeast-1.amazonaws.comにするというもの
今回は後者の方法をとった!
CentOSは言わずと知れたRedhatのクローンなので、各種パッケージのバージョンが古い(言い方を帰れば枯れて安定している)。
PHPなどは5.x系だし、MariaDBも5.5と数年前のバージョンである。
今回はXtrabackupのMariaDB対応板であるMariaBackupを試してみる必要があり、一気に最新バージョンである10.5にバージョンアップしてみた。
まず、公式サイトのワンライナーでrepositoryを追加したらあとはパッケージをインストールするだけ。
検証用のマシンなので、5.5で稼働中のまま10.5にアップデートしてみたが問題なくいった・・・ように思えて実は細かいところが。
まず既存ユーザーのパスワードがなぜか失われた。パスワードなしならログインできる。rootに関してはそのような現象は発生していなかった。
データに関しては問題なく入っているようだが、これからチェックしなければならない。
vmxファイルに以下の記述を入れる。一回だけ有効で、次回以降は元に戻る。
bios.forceSetupOnce = “TRUE”
Datadogはクラウドの監視システム
ホスト単位の課金が基本となっており、エージェントをインストールすると数分後に見ることができる。おそらく有効なエージェントの台数で課金ホストを数えていると思われる。
ホスト単位の課金の場合は5台以内に抑えておけば課金はない。
これがAWS との統合になると今度はAWSのAPIコールベースの課金となる。
AWS CloudWatch Metricsとの統合を試してみたのだが、半日動かしただけで26000のAPIコルが発生した。1000コールあたり0.1ドルなので、0.26ドルと毎月の平均予算が0.5ドル未満の我がAWSアカウントに大きなダメージが!
2020/07/10 20:00頃から主要なアプリが落ちまくるという情報が流れており、それらの共通点はFacebookのSDKを使っているということ。
SDKのバージョンによらず起きているのでこれは、Facebook側の問題であることは間違いなし。しかし一般カスタマーにはそんなこと関係なく、メルカリなどの腫瘍アプリの障害報告にはすさまじい罵詈雑言が投げられていた。
とはいえもとをたどればFacebookのような品質最低の糞サイトの連携しているからなのだが。品質を上げたければ品質の低いサイトには繋がないことであり、Facebook連携しないことなのだ!
本日とある飲食店の特集がTVで放映されていて、その後にサイトが落ちていた、または繋がらなくなったとの情報が。
調べてみるとELBが6台になっていて、通常に比べるとスケールはしているのだろうが、その後ろにあるアプリケーションがリクエストを時間以内に捌ききれずにタイムアウトしている感じであるな。
こういう時はなるべく静的ページ中心の作りにしておき、CDNにキャッシュさせておくのが定番である。店舗一覧などの動的ページにしても、URLを静的パスにして、キャッシュの時間を長めにしておくべし。
その上でオンラインショップなどの本当に動的処理が必要なものは別ドメインにするなどして、TVやYahooからのひやかしも含むアクセスから逃しておくようにしておけば、客を逃すこともあるまい!
とはいえ、電車と同じで一番はオフピークであることに違いない。明日になればELBの台数も2台ぐらいに落ち着いて、普通にアクセスできるようになるだろう!
3年以上ノンストップで運用していたAsrock Desk Mini 110
内部では実験用にESXiサーバーが動いていて、昨夜から何故か繋がらず、流石に三年だからなんかあったかなとそのままにして、翌朝調査。
とりあえず再起動させてみるが上がってこない。これはなんかあるなと思ってディスプレイに繋ぐ・・・前に恒例のホコリ掃除だが、3年分のホコリが凄まじい量であった。
そしてよくよくCPUファンの周りを掃除するとCPUファンが回らない、そこにはどす黒い大きなホコリの塊が。
あまりにホコリが溜まっていたのと最近の雨の湿気で固まったのかCPUファンを止めていて、温度上昇していたようだ。