わかりやすい

主にIT関連や時事ネタの興味を持ったことを、なるべくわかりやすく書いてみようとおもいます。

スポンサーリンク

格安SIMでおサイフケータイを使う

こんにちは、わかりやすいです。

脱二台持ち、ではありませんでした - わかりやすいの続きです。

わかりやすいが何をしているのか、結論から書いていきましょう。

目次

わかりやすいの要望

おサイフケータイ対応のスマホに格安SIMを刺している人には「使えて当然」という話かもしれませんが、自分はNexus5が超お気に入りなんです。

↑これ。DoCoMoおサイフケータイ対応端末を買ってその1台に全部集約する、というところまで気分が盛り上がらないんですよね…。

ちなみにIS05は↓こんなん。

もはや過去の遺物ですが、非常に名機だったと思います。 セキュリティパッチが当たるAndroidにアップデートできればmineo(auのSIMを提供してくれる数少ないMVNO)を契約してIS05を現役復帰、というのも無きにしも非ずですが、 それが叶わないのと、あと性能的にAndroid4系とか5系はちょっと厳しいのかなと。

さて、そうすると2台持ちでもやむなし、という考えになるわけです。

わかりやすいが行っていることと、実現できていること

以下を行っています。

  • Nexus5でWiFiテザリングを有効にする
  • IS05に、解約済みのauのSIMを刺す
  • IS05をNexus5のWiFiに接続する

これにより、IS05がおサイフケータイとして機能します。 一つ目、二つ目はIS05をインターネットにつないで、おサイフケータイのアプリで チャージとかさせるために必要、というのはなんとなくわかりますが、 二つ目の「解約済みのauのSIMを刺す」というのが、よくわからないですね。

何がポイントなのか?

以下が罠です。

SIMが刺さっていないとモバイルSuicaのアプリが起動できないんです。 解約済みのSIMでもいいのか?いいみたいです。ただし、通信事業者によっては 端末とSIMの組み合わせに制限をかけているところもあるようで、 「(契約的に通信が行えるかどうかではなく)端末が使えるSIM」を刺しておくことが必要です。

ちなみに楽天Edyは今のところSIMの確認は行っていないみたいです。

その他のおサイフケータイは使っていないのでわかりません。

というわけで、「おサイフケータイのためだけに2台持つか?」という疑問はさておき、 それがわかりやすいの望みなのです。もちろんNexus5がおサイフケータイとして機能してくれればベストなんですが。

脱二台持ち、ではありませんでした

こんばんは、わかりやすいです。

IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(報告編) - わかりやすい

でご報告したとおり、IIJmioMNPしてガラケー(電話)とスマホ(通信)はスマホ(電話&通信)になったのですが、 実は端末は相変わらず2台持っていたりします。

何事かというと、要するにおサイフケータイを使いたい、という話です。 あれ、大手通信事業者との契約がないのにおサイフケータイ使えるんだっけ? はい、使えます。使えています。少なくとも楽天EdyモバイルSuicaは。チャージも含め。

詳しくは次の記事で書こうと思います。

ハングアウトが便利

IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(報告編) - わかりやすい でも紹介したとおり、IIJmioMNPしました。 ちなみに自分はNexus5を愛用中。

ちょっと大きいけど、慣れると便利。 で、Nexus5で音声通話もできるようになったわけですが、ハングアウトでのSMSのやりとりが便利。 今までガラケーだったのもあり、ユースケースはこんな感じで変化しました。

ガラケー時代

  • 来たSMSに返信する(これはステップ数的に比較的らくちん)

    1. SMS着信アイコンを押してメールソフト起動、文面が表示される
    2. 返信ボタンを押す
    3. メッセージを入力する
    4. 送信ボタンを押す
  • SMSを新規に送信する(SMSのやりとりをする人はごく限られているので、基本は過去のSMSに返信する操作にしている)

    1. メールソフトを起動する
    2. Eメール表示からSMS表示に切り替える
    3. 送りたい相手の過去のメールを探して開く
    4. 返信ボタンを押す
    5. メッセージを入力する
    6. 送信ボタンを押す
  • Aさんとの過去のやり取りを確認する(もはや苦行)

    1. メールソフトを起動する
    2. Eメール表示からSMS表示に切り替える
    3. 過去のメールを一件一件確認する

ハングアウト時代

  • 来たSMSに返信する(返信ボタンを押す、というステップが減るだけでかなり楽になった!)

    1. 通知からタイムラインを開く
    2. メッセージを入力する
    3. 送信ボタンを押す
  • SMSを新規に送信する(これもステップが減って便利になった)

    1. ハングアウトを起動する
    2. 送りたい相手とのタイムラインを開く
    3. メッセージを入力する
    4. 送信ボタンを押す
  • Aさんとの過去のやり取りを確認する(超らくちん!)

    1. ハングアウトを起動する
    2. 送りたい相手とのタイムラインを開く
    3. スクロールスクロール

ステップ数かなり減った。便利!

わかりやすいとは何者なのか

こんばんは、わかりやすいです。

お前は何者なんだ、という方がひょっとしたらいらっしゃるかもしれないので、 公開して差し支えない範囲で興味とかスキルとか晒してみます。

  • コンピュータ全般
  • Linux
    • CentOS長く使ってます。
    • CentOS7にどうも慣れることができず、Ubuntuに浮気でもしようかと思っています。
  • ネットワーク
    • スイッチ、ルータ全般。Cisco、Juniperが一番手についてる感じ。
    • vyosとかlagopusとか興味あります。ちゃんといじってないけど。
    • ファイアウォールとかLBとかも基礎的な部分は理解しているつもり。
  • ストレージ
    • EMCとかいわゆる大手メーカー製品はあまりいじったことありません。
    • ストレージ技術全般、浅く理解しているつもりです。
    • 自宅ではLinuxでSATAx4、RAID5、LVMでiSCSIターゲット運用しています。
    • DRBDとかやってみたいけど手が出てない。
    • SATAx4程度だと遅すぎるので、SSD乗せてBcacheとかやりたい。CentOS6系でできるのかなー。
  • サーバ
    • iSCSIがあるということは、当然仮想化基盤もあります。
    • CentOS6上でKVMvirt-manager
    • OpenStackとかやりたいけど、これも手が出ていない。
  • データベース
    • MySQLを少々、PostgreSQLは長らく触っていない。
    • DB設計は普通にできてる気がする。
    • じゃんじゃんjoinしてまともな速度になるようにいろいろチューニングしたり、とか。
    • NoSQL系はあまりよくわからない。
    • MongoDBをちょっとだけ触ったことがある。
  • プログラミング
  • 業務設計とか得意だったり。
    • システムは業務ありきで設計できると幸せだと思ってます。
    • ただ、業務要件はあとからしか出てこないことも多々あり。
    • こんなときはもはやセンスだと思う。お客さんにはこういう業務要件があるんじゃないか、とか。こういうの意外と得意。

ただのたな卸し記事、御免。

MySQLでToo many connectionsが起きた場合の対処方法

表記の件について。ちなみにほとんどはブログ主の推測です。

目次

キーワード

そもそもToo many connectionsとは?

  • 「古い接続を切断しない限り、これ以上新規の接続ができません」とMySQLが言っている
  • ここでの「接続」の定義は「認証開始後~quit」と思われる
    • Too many connectionsが認証処理の後に出力されたため
    • quitは推測

関連パラメータ

  • 接続から切断まで、全ての処理が正常に進む前提なら、以下が関係しそう
    • どれだけの頻度で新規接続が行われるか
    • どれだけの時間接続されているか
      • 接続後に行われる処理はどれだけの計算量か
      • 処理を行う計算機はどれだけの性能を持っているか
  • 処理が正常に終了しない場合は以下の2パターンの処理が起こりそう
    • 異常を検知して強制的に切断する
    • ずっと接続が残り続ける
  • MySQLには上記を考慮した振る舞いを期待したくなる
  • そのためのMySQLの設定値は以下の2つ
    • max_connections
    • wait_timeout

で、結局どうすればいいのよ

以下を疑いましょう。

  • すべての処理は正常に行われているが、負荷や接続頻度の上昇によって同時接続数が増えてしまっている?
  • 特定のクエリが非常に遅かったりして、ほかの処理を阻害している?

まずは現状把握から。

  • 腐っている接続が無いか?
mysql> show processlist;
+------+--------+-------------+-------+-------------+--------+-------+------------------+
| Id   | User   | Host        | db    | Command     | Time   | State | Info             |
+------+--------+-------------+-------+-------------+--------+-------+------------------+
|   66 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |    186 |       | NULL             |
|   67 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |    186 |       | NULL             |
| 2450 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |    428 |       | NULL             |
| 2451 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |    428 |       | NULL             |
| 4725 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |     46 |       | NULL             |
| 6194 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6213 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      2 |       | NULL             |
| 6215 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6216 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6217 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |    405 |       | NULL             |
| 6218 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6219 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6221 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6222 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6225 | xxxxxx | xxxxx:xxxxx | NULL  | Query       |      0 | NULL  | show processlist |
| 6226 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6237 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
| 6238 | xxxxxx | xxxxx:xxxxx | xxxxx | Sleep       |      7 |       | NULL             |
+------+--------+-------------+-------+-------------+--------+-------+------------------+
18 rows in set (0.00 sec)

mysql>

Timeが異常に長いものとかあれば、そのIdを殺すと滞留が解消するかもしれません。 自分が遭遇した状況では、Commandに「Sending Data」というIdが存在し、 それ以外は「Lock」という状態のものが多く存在している状況で、 Sending DataのIdをkillしたら復活したことがありました。

mysql> kill 6031;
Query OK, 0 rows affected (0.00 sec)

mysql>

こんな感じ。

上記は処理が正常終了していないケースでしたが、全部正常だと、最大同時接続数の設定が そもそも足りていなかったり、タイムアウト時間が長すぎるのが原因かもしれません。

以下で現状の設定を把握します。

mysql> show global variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 100   |
+-----------------+-------+
1 row in set (0.00 sec)

mysql>
mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 28800 |
+---------------+-------+
1 row in set (0.00 sec)

mysql>

同時接続数は計算量と性能を見ながら決めることになるのかな。 wait_timeoutは秒単位で、デフォルトだと28800(8時間)とのこと。 タイムアウトがアイドルタイムアウトなのか接続開始から接続終了までの時間なのかが不明。 だけど8時間は長すぎる、と判断できる機会は多そう。今自分が面倒を見ているシステムでもそう。

設定変更(の前の注意事項)

計算機の設定を変更するときは以下に注意する必要がある。

  • 現状の動作を変更する
    • 今すぐすべてに変更が反映されるのか?(例えば「既に接続されている接続のwait_timeoutも変更されるのか?」という疑問)
    • すべてではなく、これから発生するイベントに対してか?(例えば「これから接続される接続のwait_timeoutだけが変更されるのか?」という疑問)
  • 次回起動時の動作を変更する
    • 再起動後、どのような動作となるか?

前者は動作中のプロセスに対してなんらか命令することで動作を変更させる、という設計のシステムが多い。 後者は起動時に読み込まれる設定ファイルを変更する、という設計のシステムが多い。

で、ネット上のいろんな情報を見ていると、どちらかしか紹介していない例が多い。 現状の動作変更だけやって、再起動した際の動きを考慮していないものとか。 もしくは設定ファイルを変更して軽々しくOSとかプロセスを再起動していたりとか。 構築中とかで止めることが許されるシステムならいいんですが、止められない場合はどちらも丁寧にやらなければいけないですね。

設定変更

結論は以下。

現状の動作を変更する

当然ですが、設定値はシステムの特性を考えて適切に決めてくださいね。

  • まずはwait_timeoutから
mysql> set global wait_timeout = 3600;
Query OK, 0 rows affected (0.00 sec)

mysql>
  • 次にmax_connections
mysql> set global max_connections = 200;
Query OK, 0 rows affected (0.00 sec)

mysql>

変更したらちゃんと変更されているか確認しましょう。

mysql> show global variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 200   |
+-----------------+-------+
1 row in set (0.00 sec)

mysql>
mysql> show global variables like 'wait_timeout';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| wait_timeout  | 3600  |
+---------------+-------+
1 row in set (0.00 sec)

mysql>
次回起動時の動作を変更する

自分の環境の場合は/etc/my.cnfを変更することになるみたいだった。

[mysqld]
(snip)
wait_timeout=3600
max_connections=200

止めてもいいシステムならservice mysqld restartとかでmysqlを再起動して正常に反映されるかどうか確認するといいと思います。 #わかりやすいはCentOS使っています。 ちなみにservice mysqld reloadでもいけるかもしれませんが、それで設定値が全部動作に反映するかどうかは謎です。 止めてはいけないシステムならきっと同じバージョンとかの開発・検証環境が存在するはず。そこでテストしましょう。 止めてはいけないシステムで開発・検証環境が無いなら、それはシステムの運用保守体制が残念すぎる。 仮想サーバとか簡単に調達できる昨今、性能を落とせばそのような環境は簡単に手に入る。 それが無いということは…。推して知るべし。

参考文献

今回のブログは以下を参考にしながら記載しました。

IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(報告編)

こんにちは、わかりやすいです。

IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(計画編) - わかりやすい

に書いたとおり、大手通信電話会社からIIJmioMNPしました。 いろんな事情で計画から外れたところもありますが、報告したいと思います。 もともとどういう計画だったのかは上記リンクを参照ください。

キーワード

結論

土日にXデー(通話不可期間)を当てたい(土曜日に通話停止、日曜日にSIM到着を希望する)場合は以下でいいのでは。 (※当然ですが、2015/04/27時点でのブログ主の勝手な推測です。なんの保障もありません。)

日時 n日前 イベント
XX/XX(Thu) 21:00~24:00 3 IIJmioの管理画面からSIM変更の申し込みを実施
XX/XX(Thu) 21:00~24:00 3 メールアドレス認証、正式申し込み実施
XX/XX(Thu) 21:00~24:00 3 本人確認画像アップロード
(※これをミスると順延していくので注意!)
XX/XX(Fri) 16:00頃 2 本人確認完了のお知らせを受領
XX/XX(Fri) 21:00頃 2 電話番号停止予定のお知らせを受領
XX/XX(Sat) xx:xx頃 1 電話番号停止
XX/XX(Sun) 06:00頃 0 サービス提供準備完了のお知らせをメールにて受領。
XX/XX(Sun) xx:xx頃 0 新SIM到着

なお、上記の「n日前」はSIM到着日を0日として、その前日を1日、その前々日を2日とした表記になっています。 また、本人確認業務をはじめとした各種業務は土日も動いているみたいなので、土日以外をターゲットとする場合も 基本的には上記と同じ考え方でいけるのでは、と思います。 (土日でも土日以外でも、「自分もこんな感じでやってみましたー」というご連絡をいただければこのブログ内で紹介させていただこうと思います。) ご連絡はブログのコメント欄、もしくはtwitter(https://twitter.com/wakariyatweet)までお願いします。

サマリ

今回の対応についてのサマリを書いておこうと思います。

  • 本人確認の画像アップロードでミスをしたため、Xデーが恐らく1日ずれた
  • 問題なくMNPできた
  • 電話はいつの間にか使えなくなっていたので、正確な使用不可期間は不明
    • ただ、概ね半日程度だったと思われる
  • 通信もいつの間にか使えなくなっていたが、電話よりも使用不可期間は短かった

実際のタイムライン

日時 イベント
2015/04/16(Thu) ガラケーの通信事業者からMNP予約番号をゲット
(有効期限は4/30(Thu))。
2015/04/24(Fri) 02:00頃 IIJmioの管理画面からSIM変更(MNP転入)の申し込みを実施
(次行のメールアドレス認証完了までは申し込み未完)。
2015/04/24(Fri) 02:00頃 メールアドレス認証を終え、正式に申し込みを完了。
2015/04/24(Fri) 02:00頃 IIJmioより本人確認書類画像の提出依頼をメールにて受領。
2015/04/24(Fri) 02:00頃 前行のメールに記載のURLより、
本人確認書類画像の提出を完了。
ここで免許証の裏面アップロードを忘れる。
2015/04/24(Fri) 16:00頃 本人確認書類画像再提出の依頼をメールにて受領。
2015/04/24(Fri) 16:00頃 本人確認書類画像の再提出を完了。
2015/04/25(Sat) 12:00頃 IIJmioより本人確認完了のお知らせをメールにて受領。
2015/04/25(Sat) 21:00頃 IIJmioより電話番号停止予定のお知らせを受領。
2015/04/26(Sun) 16:00頃 電話番号が停止していることに気付いた。
(アンテナピクト立ってた)
2015/04/26(Sun) 24:00頃 通信できなくなっていたような…
(時間うろ覚え…。WiFi範囲にいたのでなおさら気付かず)
2015/04/27(Mon) 06:00頃 サービス提供準備完了のお知らせをメールにて受領。
2015/04/27(Mon) 09:00頃 新SIM到着。

※時間は24時間表記です。つまり、02:00というのは夜中、ということです。

特記事項

  • 本人確認画像を提出するシステムで、複数画像のアップロードに失敗。
    • システムの画像キャプり忘れたけど、正直わかりにくいと思う。
  • SIM交換はみおぽんを見る限り、「追加」と「削除」が行われる模様。
    • ミニマムスタートプランなのに、SIMが2枚あるように表示されている。
      • 1枚は旧SIM、1枚は新SIM
    • 来月になれば旧SIMは表示から消えるのかな?

IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(計画編)

※2015/04/27追記 報告編書きました。IIJmio mio高速モバイル/D(データ通信専用SIM or SMS機能付きSIM)契約者が同サービスにMNP転入する場合のベストプラクティス(報告編) - わかりやすい

今月、大手携帯電話会社から脱却して、今までデータ通信のみで使っていた格安SIM(BIC SIM)にMNPしてモバイル関連の契約(音声・データ通信)を一本化します。 この記事はBIC SIM(IIJmio)のSIM交換+MNPを前提にしているので、BIC SIM(IIJmio)新規契約+MNPをしたい方は、ビックカメラの店舗にある BIC SIMカウンターで即日MNPをするか、以下を買って対応することになると思います。

BIC SIMカウンターでの即日MNPではなく、上記を購入してMNPされる方には、どういう時系列で対応するとどうなるか、については参考になるかもしれません。 ただ、以下はあくまで予定(計画)です。報告は後日別記事を書こうと思います。

なお、お約束ですが本ブログを読んだことで発生したいかなる直接的・間接的損害についても、ブログ主は一切責任を負いません。

キーワード

目的

  • 通信料金の削減

前提

  • モバイル端末2台持ち
    • スマホ
      • 端末: Google Nexus5
      • 通信契約: BIC SIM ミニマムスタートプラン データ通信専用SIM
    • ガラケー
      • キャリアメールと音声通話のみに利用

要件

  • BIC SIMの解約・新規は行わない(公衆無線LANのアカウントが変わるかもしれない?根拠なし。)
  • スマホの通信が使えない期間は基本的に作らない
  • 音声通話が使えない期間はなるべく短く、かつ土日に収まるようにする
  • キャリアメールは廃止する

方針

  • BIC SIMのSIM変更でMNPする
  • BIC SIMのプランはミニマムスタートプランから変えない
  • 2015/04/25(Sat), 2015/04/26(Sun)の2日間を、切替に伴う断発生日となるように調整する

予定

日付 イベント
~2015/04/22(Wed) ガラケーの通信事業者からMNP予約番号をゲットする。
2015/04/23(Thu) 18:00~21:00 IIJmioの管理画面からSIM変更(MNP転入)の処理をする。
本人確認画像も即アップロードする。
2015/04/24(Fri) IIJmioにて本人確認が完了する予定。
2015/04/24(Fri) 夜 IIJmioより電話番号停止予告が来る予定。
2015/04/25(Sat) 昼前 電話番号停止予定。
2015/04/26(Sun) 夜 新SIM到着予定。

お金のはなし

初期費用

項目 支払先 金額(税込み)
MNP転出手数料 ガラケー通信会社 \2,160
SIMカード交換手数料 IIJmio \2,160
MNP転入手数料 IIJmio ???(調べたけど見つからなかった)
プリペイドSIM 家電量販店 \4,000程度
合計 \8,320+MNP転入手数料

月額費用

MNP転入前は以下(実はこの時点ですでにかなり節約できている)

項目 支払先 金額(税込み)
スマホ通信料 IIJmio \972
ガラケー通信料 ガラケー通信会社 \3,000程度(メール、通話料込み)
合計 \4,000程度

MNP転入後は以下

項目 支払先 金額(税込み)
スマホ通信料 IIJmio \1,728+通話料(\2,000くらいか?)
合計 \3,800程度

うーんあまり安くならないな。 まぁ二台持ちから開放されると思えば…。

続報をお楽しみに!