MVNOを比較する観点
こんにちは、わかりやすいです。
格安SIMとかのことばっかり書いてますね。 さてさて、格安SIMを選ぶ場合の観点を整理しておこうと思います。
格安SIMを選ぶ場合の観点
- 実質的な通信品質
- 言わずもがな、SIMの主機能
- 「費用対効果」の「効果」にもっとも重要な影響を与えるべき項目
- 宣伝文句としての「無制限」とか「xxxMbps（理論上の以下略）」みたいなのはあてにならないので、twitterとかでユーザの声を聞くのが一番
- その中でも重要なのが「一般的な混雑時間帯（平日12:00～13:00）での使い心地」
- サポート
- 価格
で、どこがおすすめなのよ
IIJmio（ただし買うのは公衆無線LANが無料で付いているBIC SIM）一択。理由は以下。
真摯な姿勢
てくろぐ: とか IIJmio (@iijmio) | Twitter とか見てて、本当に生真面目にユーザに向き合っていると思う。
サービスの仕様に納得感がある
前述の「真摯な姿勢」の結果に過ぎないのだけど、例えば最低契約期間の設定。 契約時の初期対応や解約時の対応のコストを考えると、「あまり短期間で解約されると収益性に問題が出る」のはよく理解できる。 で、具体的な最低契約期間の設定について、代表的には以下の2パターン。
- いわゆるx年縛り
- いつでも解約可能だが、基本的に解約時には違約金が発生する
- x年に1ヶ月だけ、違約金が発生しない月が巡ってくる
- 最低xヶ月利用
- いつでも解約可能だが、利用期間に応じて違約金が発生する
- xヶ月以上利用は違約金が発生しない
- 利用期間が短ければ短いほど違約金が高くなる
- いつでも解約可能だが、利用期間に応じて違約金が発生する
より高い収益性や売上げ見込みの正確性を考えれば前者になる。つまり、契約した瞬間にその人が向こうx年間でいくら支払うかが確定する。 世の中にこの方式しかないのであれば気付かなかったかもしれないが、後者が出てきたことで、前者の見方が変わる。
x年縛りは「利用者のサービス選択の自由」を奪っているように見える。 解約のリスクを通信事業者が極力負わないようになっている。
後者はどうか。前者と比べ、利用者のサービス選択の自由はかなり確保されていると感じる。 その分xヶ月以降は解約障壁が下がるため、通信事業者は解約のリスクを負うことになる。 けど、市場原理ってこういうことだと思う。自信がないと取れない戦略。
「絶対に永く使っていただけるようなサービスであり続けるんだ」
そんな意気込みをどうしても感じてしまう。
高い技術力
永く使ってもらいたいと願うだけではダメで、いいサービスを提供するためにどれだけ努力しているかが重要だと思います。
自分はIT（特にインフラとかネットワークに強い）エンジニアなので書いてある内容はざっくり理解できるんですが、
てくろぐ: MVNOのメール・iPhone VoLTEとみおふぉんダイアル・Androidスマホの不安定な挙動を調査 (IIJmio meeting 7 資料公開)
これとかすごい。まじめ。高い技術力。 OCNとかビッグローブとかソネットとかNiftyとか日本通信(b-mobile)とか他社の状況もいろいろ調べていますが、 このレベルでまじめに取り組んでいる（ことがインターネット上で読み取れる）のはIIJmioのみ。 IIJの歴史とか調べてみると、あぁなるほどね、という感じです。通信とかインターネットに対するプライドが桁違い。
IT屋としてほんとお勧めです。IIJmio。
IIJmioを知ると惚れ込んで他を利用する気がなくなりますが、 目下の課題は平日12:00～13:00の混雑。確かに前より使用感が悪い。 利用者（というより利用帯域）増に設備増強が間に合っていないと思われる。 まぁでもすぐ改善されるでしょう。この状況を長く放置するような事業者じゃない。
格安SIMでおサイフケータイを使う
こんにちは、わかりやすいです。
脱二台持ち、ではありませんでした - わかりやすいの続きです。
わかりやすいが何をしているのか、結論から書いていきましょう。
目次
わかりやすいの要望
おサイフケータイ対応のスマホに格安SIMを刺している人には「使えて当然」という話かもしれませんが、自分はNexus5が超お気に入りなんです。
↑これ。DoCoMoのおサイフケータイ対応端末を買ってその1台に全部集約する、というところまで気分が盛り上がらないんですよね…。
ちなみにIS05は↓こんなん。
もはや過去の遺物ですが、非常に名機だったと思います。 セキュリティパッチが当たるAndroidにアップデートできればmineo（auのSIMを提供してくれる数少ないMVNO）を契約してIS05を現役復帰、というのも無きにしも非ずですが、 それが叶わないのと、あと性能的にAndroid4系とか5系はちょっと厳しいのかなと。
さて、そうすると2台持ちでもやむなし、という考えになるわけです。
わかりやすいが行っていることと、実現できていること
以下を行っています。
これにより、IS05がおサイフケータイとして機能します。 一つ目、二つ目はIS05をインターネットにつないで、おサイフケータイのアプリで チャージとかさせるために必要、というのはなんとなくわかりますが、 二つ目の「解約済みのauのSIMを刺す」というのが、よくわからないですね。
何がポイントなのか？
以下が罠です。
- モバイルSuicaは起動時にSIMの確認を行っている
SIMが刺さっていないとモバイルSuicaのアプリが起動できないんです。 解約済みのSIMでもいいのか？いいみたいです。ただし、通信事業者によっては 端末とSIMの組み合わせに制限をかけているところもあるようで、 「（契約的に通信が行えるかどうかではなく）端末が使えるSIM」を刺しておくことが必要です。
ちなみに楽天Edyは今のところSIMの確認は行っていないみたいです。
その他のおサイフケータイは使っていないのでわかりません。
というわけで、「おサイフケータイのためだけに2台持つか？」という疑問はさておき、 それがわかりやすいの望みなのです。もちろんNexus5がおサイフケータイとして機能してくれればベストなんですが。
脱二台持ち、ではありませんでした
こんばんは、わかりやすいです。
IIJmio mio高速モバイル/D（データ通信専用SIM or SMS機能付きSIM）契約者が同サービスにMNP転入する場合のベストプラクティス（報告編） - わかりやすい
でご報告したとおり、IIJmioにMNPしてガラケー（電話）とスマホ（通信）はスマホ（電話＆通信）になったのですが、 実は端末は相変わらず2台持っていたりします。
何事かというと、要するにおサイフケータイを使いたい、という話です。 あれ、大手通信事業者との契約がないのにおサイフケータイ使えるんだっけ？ はい、使えます。使えています。少なくとも楽天EdyとモバイルSuicaは。チャージも含め。
詳しくは次の記事で書こうと思います。
ハングアウトが便利
IIJmio mio高速モバイル/D（データ通信専用SIM or SMS機能付きSIM）契約者が同サービスにMNP転入する場合のベストプラクティス（報告編） - わかりやすい でも紹介したとおり、IIJmioにMNPしました。 ちなみに自分はNexus5を愛用中。
ちょっと大きいけど、慣れると便利。 で、Nexus5で音声通話もできるようになったわけですが、ハングアウトでのSMSのやりとりが便利。 今までガラケーだったのもあり、ユースケースはこんな感じで変化しました。
ガラケー時代
来たSMSに返信する（これはステップ数的に比較的らくちん）
- SMS着信アイコンを押してメールソフト起動、文面が表示される
- 返信ボタンを押す
- メッセージを入力する
- 送信ボタンを押す
SMSを新規に送信する（SMSのやりとりをする人はごく限られているので、基本は過去のSMSに返信する操作にしている）
- メールソフトを起動する
- Eメール表示からSMS表示に切り替える
- 送りたい相手の過去のメールを探して開く
- 返信ボタンを押す
- メッセージを入力する
- 送信ボタンを押す
Aさんとの過去のやり取りを確認する（もはや苦行）
- メールソフトを起動する
- Eメール表示からSMS表示に切り替える
- 過去のメールを一件一件確認する
ハングアウト時代
来たSMSに返信する（返信ボタンを押す、というステップが減るだけでかなり楽になった！）
- 通知からタイムラインを開く
- メッセージを入力する
- 送信ボタンを押す
SMSを新規に送信する（これもステップが減って便利になった）
- ハングアウトを起動する
- 送りたい相手とのタイムラインを開く
- メッセージを入力する
- 送信ボタンを押す
Aさんとの過去のやり取りを確認する（超らくちん！）
- ハングアウトを起動する
- 送りたい相手とのタイムラインを開く
- スクロールスクロール
ステップ数かなり減った。便利！
わかりやすいとは何者なのか
こんばんは、わかりやすいです。
お前は何者なんだ、という方がひょっとしたらいらっしゃるかもしれないので、 公開して差し支えない範囲で興味とかスキルとか晒してみます。
- コンピュータ全般
- Linux
- ネットワーク
- ストレージ
- サーバ
- iSCSIがあるということは、当然仮想化基盤もあります。
- CentOS6上でKVM、virt-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転入する場合のベストプラクティス（計画編） - わかりやすい
に書いたとおり、大手通信電話会社からIIJmioにMNPしました。 いろんな事情で計画から外れたところもありますが、報告したいと思います。 もともとどういう計画だったのかは上記リンクを参照ください。
キーワード
結論
土日に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は表示から消えるのかな？
- ミニマムスタートプランなのに、SIMが2枚あるように表示されている。
