著者アーカイブ takahashi

著者:takahashi

欧州などを管轄するRIPE NCCのIPアドレス在庫が枯渇。迫るIPアドレス不足対策のリミット。

話題に上ってから久しい、IPv4アドレスの在庫枯渇問題ですが、ここ数年の間に実際に多くの管理団体で、未使用のIPアドレス在庫が枯渇する状況になっています。

日本をはじめとするアジア地域でのIPv4アドレス在庫を管理していたAPNICでも、2011年4月5日にすでに新規のIPアドレス在庫が枯渇しています。

IPv4アドレスの在庫枯渇に関して – JPNIC

そして先日、ヨーロッパ地域などを管轄するRIPE NCCの所有IPv4アドレス在庫も枯渇したとのニュースが流されました。

欧州地域のIPv4アドレスがついに枯渇 – ZDNet Japan

これで、新規IPv4アドレスの在庫がまだ残っているのが、アフリカを中心としたAFRINICの管理するIPアドレスのみとなりました。
（※AFRINICはもともと在庫数が少なく、他のRIRへの移転が認められていないため、IPアドレス在庫があっても他国の事業者が使用することはできないようです。)
AFRINIC 26レポート [前編] ～全体概要～ – JPNIC BLOG

まだ中古ドメインの取り扱いは一部あるようですが、明らかに需要に対してアドレス数が足りていないため、いよいよもって根本的な対策が必要となってきました。

しかし、移行先の第一候補であるIPv6はIPv4とほぼ互換性がなく、IPv4しかないネットワーク、およびその逆の場合は相互に通信を行うことができないのが最大の難点となっています。

全世界で一斉に切り替えることは無理なので、影響を最小限に抑えつつもスムーズに移行する方法が必要になってきますが、既存の仕組みだけではなかなか難しいのが現状のようです。

うまいやり方が見つかればよいのですが…

著者:takahashi

Google Chromeに実装された新機能の影響で多くのサイトで不具合が発生

先日、次のような不具合の情報が、銀行や申込フォームなどがあるサイトなど、様々なサイトでアナウンスされました。

【システム障害】ろうきんダイレクト（インターネットバンキング）一部取引における不具合について – 近畿ろうきん

インターネットバンキング（個人）における一部不具合について（続報) – 島根銀行

【お知らせ】Android版chromeでWEB投票をご利用中にエラーが表示される事象について – BOAT RACE

Android版Chromeにおける各種不具合について – mixi

上記のサイト以外にも、楽天市場やmineoなど、多くのサイトで影響が出ていたとのこと。

具体的な内容としては、Android版Google Chromeでこれらのサイトを閲覧すると、サイトの動作に不具合が発生し、セッションが切れてしまったり、不正な操作が行われてしまうといった少々まずい症状のようです。

・原因はAndroid版GoogleChromeの新機能、”プリロード”

原因は最近Android版Google Chromeに搭載された”プリロード機能”によるもののようです。

AndroidのChrome 78のPreload問題 – Qiita

このプリロード機能は、サイト内のaタグ（クリックすると別のページを表示するいわゆるリンクのこと）をすべてスキャンし、aタグで指定されているリンク先URLのページまでも先読みしてしまうことで、表示速度を高速化しよう、という機能だったようです。

ところが、サイト内のaタグに含まれるすべてのURLのページに無差別にアクセスする仕組みになっていたために、ユーザーがタップしていないにも関わらずログアウトボタンが動作してしまったり、ショッピングサイトなどのページ遷移が厳しく管理されているサイトなどでは不正なページ遷移が発生し操作ができなくなる、といった状況が多数発生したのが今回の問題の原因だったようです。

すでにChromeの開発チームには報告されており、直ちに無効化の操作が行われ、現在は一度GoogleChromeを再起動することでこの問題の機能が無効化されるようになっているとのことです。

しかし、まだ設定項目は残っているようで、何かのはずみに再び有効になってしまうことも考えられます。

一応設定からも無効にしておくと安心です。

Chromeの”設定”から

プライバシー->”ページをプリロードして、閲覧と検索をすばやく行えるようにします”

のチェックボックスをオフにすることで、プリロード機能を無効化できます。

しかし、明らかに既存のサイトでの動作に影響が出そうなこの機能が、どうして正式リリースまで出てしまったのか…非常に疑問ですね。

著者:takahashi

dockerのMySQLコンテナでなぜ”command: –innodb-use-native-aio=0″が必要な環境があるのか

ここ最近人気のコンテナ型仮想化技術であるDockerですが、Linuxを前提とした仕組みのため、他のOSではLinuxのカーネル何らかの方法で動作させ、そのうえでdockerを実装させる仕組みをとっています。

実はこの仮想化の方法によってはDockerでMySQLを動作させる際にdocker-compose.ymlを編集しないとMySQLが動作しない場合があります。

具体的には、Docker Toolboxで動作させた場合、docker-compose.tml内のMySQLの設定セクションで

command: --innodb-use-native-aio=0

を入れておかないとエラーになるというものです。

dockerでmysqlが起動できない。 – Fworx Tech Blog

なぜ上記の指定が必要かというと、デフォルトでは、データベースエンジン InnoDBの”非同期ディスク I/O”という機能が有効になっているのですが、このDockerToolboxなどの環境ではこの機能が利用できないようで、起動時にエラーになってしまう状況のようです。

なので、

--innodb-use-native-aio=0

のオプションを指定して非同期ディスクI/Oを無効化することでDocker Toolboxなどでも動作させることができるようになる、ということのようです。

せっかくどの環境でも同じ開発環境が実現できるようにdockerを使用しているのに、OSによってオプションを変えないといけない、というのはちょっと辛いものがありますね。

OSごとに異なる設定を読み込ませるような指定があればいいのですが…

著者:takahashi

楽天カードに大規模障害が発生した件で思うこと

先日、 楽天カードでなかなかヤバい障害が発生していましたね…

【一部復旧】当社サービスの一時利用停止のお詫びとお知らせ
（株式会社QTnetの電源設備更新作業に伴う不具合）- Rakuten Card

上記記事によると、2019年11月23日(土)6時ごろから、楽天カードや楽天ペイ、およびこれらサービスの利用明細確認などの機能が障害により停止し、なんとカード決済までも止まってしまう障害が発生していました。

カード決済機能と楽天Payは当日中に復旧しましたが、明細確認機能などはこの記事作成時点においてもまだ復旧していません。

原因は楽天カードの決済サーバーが置かれているQTnet社のデータセンターで、電源設備入れ替え時に電源障害が発生し電源が一瞬落ちたそうで、それが原因で同データセンターで稼働していたサービスが影響を受けてしまったようです。

この関係で、楽天以外にも、同データセンターにサーバーを置いていた官公庁や電力会社のHPにも障害が発生していたようです。

楽天カードなど260社・自治体に影響　九電系で障害 – 日本経済新聞

入れ替え中とはいえ、データセンターで電源を一瞬でも落としてしまうというのはあってはならない障害ですが、AWSですら電源ではないですが設備設定の入れ替えで障害を起こしたこともあるぐらいで、残念ながらデータセンターであっても障害が起きるときは起きてしまうものです。

個人的に、今回一番に問題に感じたのは楽天側のシステム構成の問題。

費用の問題もありますし、ダウンタイムが許容されるようなサービスであれば単一データセンターで動かしていたとしても理解はできます。

しかし、楽天カードはクレジットカードという超重要な社会インフラですし、たとえそれなりのコストがかかったとしても、決済機能だけでも絶対に止めてはいけないシステムであったはずです。

最近ではクレジットカードをメインに使用し、現金を持ち歩かない人も増えているようですが、もし食事やサービスを利用した際に現金をもっていない状況で(利用者側の落ち度なく)カードの利用ができなくなってしまっていたら、利用者がどのような状況に陥るのかは想像に難くありません。

生活費をカードで決済している場合もあります。

また楽天カードはETCも発行しています。

実際に起きていたかどうかはわかりませんが、決済ができないということはETCなどでの利用でも問題が発生した可能性もあると思います。

もし出場時に問題が発生して出られなければ、利用者はパニックに陥りかねないとおもいます。

停止すれば日常生活に実害をもたらしてしまう可能性のあるサービスが、単一のデータセンターが障害されただけで止まってしまうという状況は、楽天カード側の障害対策が甘すぎると感じました。

今回は電源断でしたが、万が一そのデータセンターが災害などに巻き込まれて完全に破壊されてしまったら、どう復旧するつもりなのでしょうか。

もう少し、耐障害性のことを考えたシステム設計にすべきなのではないかと個人的には感じました。

今後の対策に注目したいと思います。

著者:takahashi

Windowsでファイルのハッシュ値を取得する方法

フリーソフトやLinux系OSのインストーラのISOなど、インターネット上から自由に入手できるソフトウェアにはよく、”チェックサム”と呼ばれる値がついていることがあります。

このチェックサムとは何かというと、

ある関数を使って特定のデータを計算すると必ず同じ値が得られ、1ビットでもデータが異なった場合は異なった値が出力されるアルゴリズム=ハッシュ関数

によって出された、ダウンロード対象ファイルのハッシュ値のことです。

つまり、公開する側が正規のファイルのハッシュ値を計算したものをを公開しておくことで、そのファイルを入手した人が同じハッシュ関数を使って”本物のファイルが入手できたのか”を簡単に確かめられるようにしてある、ということです。

例えば、もし何らかの方法でダウンロードするファイルが不正にすり替えられていたとしても、1ビットでも異なれば別のハッシュ値が出力されてしまうため、手元のファイルのハッシュ値と比較することで手元のファイルが改ざんされたものかどうかを簡単に調べることができます。

そんなセキュリティ的にも重要なハッシュ関数ですが、WindowsではGUIのツールがデフォルトで用意されているわけではないため、ハッシュ関数の存在を知っていてもセットアップのめんどくささからあまり使わないユーザーも多いのではないかと思います。

実は、コマンドプロンプト上のコマンドによる操作にはなってしまいますが、Windowsに始めからインストールされている、CertUtil というコマンドで簡単にファイルのハッシュ値を求めることができます。

コマンドの使い方としては

CertUtil -hashfile ハッシュ値を出したいファイルのパス ハッシュ関数

のように指定します。

実行すると下記のようになります。

Microsoft Windows [Version 10.0.18362.476]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\hoge>CertUtil -hashfile C:\Users\hoge\Downloads\linuxmint-19.2-mate-64bit.iso sha256
SHA256 ハッシュ (対象 C:\Users\hoge\Downloads\linuxmint-19.2-mate-64bit.iso):
56f2d0c2b54be0fd66a8cf35799a69d02d4bfdf546b4f946a0b8af01cbbbd689
CertUtil: -hashfile コマンドは正常に完了しました。

C:\Users\hoge>

上記の例はLinuxMintのOSのインストーラーイメージをハッシュ関数にかけた時の結果です。

56f2d0c2b…の一行がハッシュ値となります。

このハッシュ値を公式サイトで公開されているハッシュ値と照らし合わせます。

ばっちり合致したので、改ざんがないことがわかりました。

こういったひと手間をかけるだけでも、ウイルスの被害などから身を守ることができますので、是非積極的に利用していきたいですね。