わかりやすい

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

スポンサーリンク

節税~法人役員編~

法人役員のための効果的な節税方法を検討してみる。 厳密には税とは呼ばれないものも低減させているが、便宜上これらを節税と呼ぶことにする。

前提

  • 法人役員
  • 配偶者控除なし
  • 子2人(3歳・0歳)
  • 役員報酬50万(年収600万)
  • 自宅は賃貸(10万/月)
  • 社会保険料所得税・住民税・子の保育料を下げて手元に残るお金を増やすことを目指す
  • 結果的に厚生年金保険料が下がって将来年金額が下がるが、それ以上に節約・節税できる(将来年金額の低下は我慢する)前提とする

どノーマル

  • 額面年収600万
  • 社会保険料の自己負担分: \70,230/月、\842,760/年
  • 所得税・復興特別所得税: \355,800
    • 課税所得: \3,880,000
      • 給与所得: \4,260,000
        • 給与収入: \6,000,000
        • 給与所得控除: \1,740,000
      • 基礎控除: \380,000
      • 社会保険料控除: \842,760
  • 住民税(翌年分): \395,500/年, \32,900/月
    • 課税所得: \3,930,000
      • 給与所得: \4,260,000
        • 給与収入: \6,000,000
        • 給与所得控除: \1,740,000
      • 基礎控除: \330,000
      • 社会保険料控除: \842,760
  • 保育料: \774,720/年, \64,560/月

額面年収から社会保険料所得税・住民税・保育料を引いた金額(手元に残る金額)は\3,631,220。 月額にすると\302,602。 家賃を控除すると年額\2,431,220, 月額\202,602。

ちなみに会社負担額は\6,000,000+社会保険料の会社負担分\842,760。

やれる限りの節税を実施

会社負担額が変わらないよう、役員報酬も変える。

  • 企業型確定拠出年金: \55,000/月, \660,000/年
  • 自宅の社宅化: \30,000/月, \360,000/年
  • 額面年収450万
  • 社会保険料の自己負担分: \53,374/月、\640,488/年
  • 所得税・復興特別所得税: \61,200
    • 課税所得: \1,199,000
      • 給与所得: \3,060,000
        • 給与収入: \4,500,000
        • 給与所得控除: \1,440,000
      • 基礎控除: \380,000
      • 社会保険料控除: \640,488
      • 小規模企業共済: \840,000
  • 住民税(翌年分): \127,300/年, \10,600/月
    • 課税所得: \1,249,000
      • 給与所得: \3,060,000
        • 給与収入: \4,500,000
        • 給与所得控除: \1,440,000
      • 基礎控除: \330,000
      • 社会保険料控除: \640,488
      • 小規模企業共済: \840,000
  • 保育料: \291,120/年, \24,260/月

額面年収+確定拠出年金+自宅家賃浮いた分(計600万)から社会保険料所得税・住民税・保育料を引いた金額(手元に残る金額)は\4,879,892。 月額にすると\406,658。 会社に支払う家賃を控除すると年額\4,519,892, 月額\376,658。

ちなみに会社負担額は\4,500,000+確定拠出年金\660,000+家賃差額\840,000+社会保険料\640,488。

節税策概要

今回実施を想定した節税策は以下。

  • 企業型確定拠出年金
    • 最大\55,000/月、報酬でないかたちで貯蓄することになる
    • 報酬でないので社会保険料所得税・住民税の課税対象にならない
    • 住民税が下がるので保育料も下がる
    • 60歳まで引き出せないので、キャッシュフローは悪化する
  • 自宅の社宅化
    • もともと報酬の中から払っていた\100,000/月を会社で支払うことにした
    • 規定の計算式に基づいて社宅料を会社に支払う必要があり、今回は\30,000/月とした(不動産課税標準額等に依存。詳細省略。)
    • 実質的に\70,000/月を報酬でないかたちで会社から個人に移転できている
    • 報酬でないので社会保険料所得税・住民税の課税対象にならない
    • 住民税が下がるので保育料も下がる
    • 支払い方を変えただけであり、キャッシュフローに大きな影響は無い
  • 小規模企業共済
    • 会社役員・個人事業主が加入できる、独立行政法人 中小企業基盤整備機構が運営する退職金制度的なもの
    • 最大\70,000/月、個人の可処分所得(報酬)の中から積み立てすることになる
    • 報酬の中から払うことになるので、社会保険料を減らす効果はない
    • ただし、所得税・住民税ともに課税所得から控除される(所得税・住民税が下がる)
    • 住民税が下がるので保育料も下がる
    • 60歳まで引き出せないのでキャッシュフローは悪化するが、積立金の一定割合分は低年利率(0.9%~1.5%)で貸付けを受けられるため、対策の余地はある

節税効果概要

トータルの節税効果は以下のような感じでした。

  • 社会保険料: \842,760/年→\640,488/年=\202,272/年
  • 所得税: \355,800/年→\61,200/年=\294,600/年
  • 住民税: \395,500/年→\127,300/年=\268,200/年
  • 保育料: \774,720/年→\291,120/年=\483,600/年
  • 合計: \1,248,672/年

考察

  • 各科目ともかなりの節約ができている。その中でも保育料の低減幅が大きい。
  • 当初額面の20%も差が出るのはかなり大きい
  • 企業負担は実は増えているはず
    • 企業型確定拠出年金の制度利用に掛かるコスト
    • 社宅運用に掛かるコスト
  • 確定拠出年金・小規模企業共済ともに、税金の先送りに過ぎない?
    • 積み立てたものを引き出す際に所得税が課税されるので上記指摘は間違いではないが、いずれも退職所得控除対象になるため、大幅な減税効果が得られる。
    • ただし、引き出し前後の期間で別の退職所得を受け取っている場合、退職所得控除にならないケースがあるので引き出し(解約)の時期・順番は要注意。
  • 小規模企業共済によるキャッシュフロー悪化は、貸付で緩和可能。
    • 年率0.9%~1.5%で貸付が受けられる。所得税で5%や10%、場合によってはそれ以上持っていかれることを考えると、小規模企業共済に入って貸付を受けたほうが得のように思われる(節税金額が貸付利息を上回る)。

EclipseにTomcat Pluginがインストールできない

気づいたら1年以上更新してなかった。

Eclipse(とかPleiades)に、Tomcat PluginをEclipseマーケットプレースからインストールしたら 「handshake_failure」とかが出てインストールできなかったので回避策を備忘録的にメモしておく。

原因(推測含む)

  • EclipseTomcatプラグインをインストールする際にSSLを使用している模様
  • Eclipseを動作させているJREのバージョン?によってはSSLを使用するためのライブラリが古い?
  • 結果的に、信頼されるべきSSL接続先サーバ(プラグインダウンロード元)が信頼されず、冒頭のエラーが表示される

対策

stackoverflow.com

上記に記載のとおりだが、原因のところに書いた「Eclipseを動作させているJREのライブラリを更新する」ことで解消可能。以下、抜粋。

  1. http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html から対象ファイルをダウンロード
  2. 解凍したファイルを(Eclipseディレクトリ)\jre\jre\lib\security\ にコピー(旧ファイルは念のため別名に変更して保存しておく等しておくときり戻せます)
  3. Eclipseを再起動する

これで冒頭のエラーは出なくなるはず。

東京都知事選挙 選挙費用はまるまる無駄なのか?

表記の件。

舛添さんの適否とか辞めることの是非は対象外。

何と何を比較すべきか、的外れな記事をよく見かけますが、 「任期を全うした場合」と「そうでない場合」を比較すべきでしょう。 つまり「選挙に50億円かかる、50億円が無駄に費やされた」は正しくない。

任期を全うした場合

もともと4年に1度、約50億円は必要。これが地味に重要。 従って、無投票とか特殊な事情が無い限りは年平均12.5億円はどうしても発生する

2年4ヶ月で選挙になった場合

どう解釈するか難しいところですが、

  • 約50億円が必要になるタイミングが1年8ヶ月前倒された

上記は事実でしょう。で、もう少しいくら無駄になったのか、という観点で考えると、

  • 本来約50億円で4年間維持できていたはずのものが、2年4ヶ月しか維持できなかった
  • 年平均12.5億円で済むはずが、年平均約21.43億円かかってしまった

つまり、年間8.93億円余計にお金がかかる。 在任期間の2年4ヶ月に換算すると20.83億円余計にお金がかかったことになる。

当たり前の話ですが、選挙費用だけ考えれば、短命な政権はコストパフォーマンスが悪いですね。 その金額は今回の例で言えば2年4ヶ月で20.83億円無駄になった、といっていいかなと。

ただの算数の話でした。

ext4はIOストールでデータロスが発生する?

ログちゃんと取ってないけど、以下のような事象が確認できた。

目次

構成

やったこと

  • イニシエータからターゲットにログイン
  • イニシエータ側でパーティションを作成、ext4でフォーマット
  • イニシエータ側でディスク(というかページキャッシュ)にデータを継続的に書き出し(追記)つつ、IOを止める(ターゲット側でネットワークを閉塞する)
  • (IO停止区間。30秒くらい。つまり、IOエラーがアプリに返らない程度。)
  • IOを再開させる(ターゲット側でネットワークを開放する)

期待した動作

追記ファイルをtailしながら。

  • IO停止前は書いたものがそのまま表示される(ページキャッシュに書き込まれ、OSが非同期にディスクにflushする)
  • IO停止中も書いたものがそのまま表示される(ページキャッシュに書き込まれるものの、ディスクへのflushが失敗する。書き込み保留。)
  • IO再開後、書き込み保留していたものも含めてすべてのデータがディスクにflushされる(データの破壊や欠損は無い)

ext4で実際に発生した現象

  • IO停止前は当然問題なし
  • IO停止後、数秒してtailの表示が止まった…(ページキャッシュへの書き込みができなくなった?)
  • IO再開後、書き込みが再開されたものの、データの欠損が発生した

具体的にはsleep 0.1しながらdate >> fileとかで書いているので、

2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST
2016年  4月 22日 金曜日 11:37:34 JST←データ欠損!
2016年  4月 22日 金曜日 11:37:52 JST←データ欠損!
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST
2016年  4月 22日 金曜日 11:37:52 JST

イメージ的にはこんな感じ。

xfsでやってみると

欠損しない。tailも止まらない(ファイルというかページキャッシュへの書き込みが継続する)。

まとめ

  • 事実としては理解したが、理由がよくわからない
  • ファイルシステムから見たらデバイスがiSCSIだろうがSCSIだろうがブロックデバイスには変わりないので、他のブロックデバイスでもIOストールでデータ欠損が起きるのでは?
  • 識者の方、推測でもいいので是非お考えをご教示いただきたく…

追記

xfsでも同じ現象が起きた。時間か何かの量かはわからないけど、IOのストール時間が長いとxfsでも書けなくなる。

熊本県で発生した地震時にLINE Outを一部無料化したLINEさんの見解とその考察

表記の件。

目次

おさらい

熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方 - わかりやすいのおさらいになりますが、

  • LINEさんの「LINE Out 1通話10分まで無料」施策は、結果的に被災地の電話網の不要な負荷増に加担してしまった可能性が高い
  • 届出電気通信事業者とはいえ、電気通信事業を行う会社として、法の趣旨に反した非常に軽率な行動だったと言わざるを得ない

これが当サイトの考察。

今日はここをもう少し掘り下げて、

  • どうして軽率な行動を取るに至ったのか?

ここを考えてみようと思います。

どうして軽率な行動を取るに至ったのか?

原因の仮説を考えてみます。 数字が大きいほど高次元の問題であることを意味します。

  • 1.影響を考えようとする人も仕組みも存在しない
    • 残念ながらレベルが低すぎるといわざるを得ない
  • 2.影響を考えたけど、電話網への悪影響まで考えが及ぶ人材が社内に存在しない
    • 人材・能力不足
  • 3.電話網への悪影響まで考えが及ぶ人材は社内に存在するものの、その人材へ連絡を取る必要性を考えなかった
  • 4.その人材へ連絡を取ろうとしたが、連絡が取れず、スピードを優先して実施に踏み切った
  • 5.その人材へ連絡が取れ、実施すべきでないとしたが、何らかの判断(ほかに考えられるメリットのほうが大きい、等)により実施することとした

さて、ここでLINEさんの見解から、仮説を絞り込んでみましょう。

LINEさんの見解

一時情報源はBuzzFeed Japanさんの模様。

www.buzzfeed.com

関係しそうな部分を、文意が損なわれないと私が考える範囲で引用します。

本施策の実施判断は、LINE Outの通常利用率やこれまでの災害時の無料化実施時の利用増加率、被災地から被災地外へのLINE Out通話・発信については輻輳リスクが低いこと、PSTNのバックボーンを担当している事業者への事前確認、などを判断材料としましたが、最も多くの利用が想定される被災地外から被災地へのLINE Out通話・発信は、輻輳リスクを高めることは事実であり、輻輳リスクを最大限低減させるという点においては、考慮・配慮が充分ではなかったと認識しております。

その告知についても、災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点、LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限るなどの注意点をお知らせ出来ていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点です。

さて、仮説を見直してみましょう。

どうして軽率な行動を取るに至ったのか?

あくまでLINEさんの事後発表なので事実かどうかはわかりませんが、とりあえず信じるとします。

  • 1.影響を考えようとする人も仕組みも存在しない

これは違うようです。赤字で書いたように、ちゃんと影響を考えたと言っています。

  • 2.影響を考えたけど、電話網への悪影響まで考えが及ぶ人材が社内に存在しない

「PSTNのバックボーンを担当している事業者への事前確認」は行っているようなので、影響は考えたようです。 ただ、以下が謎です。

  • PSTNのバックボーンを担当している事業者とは誰で、その事業者に何を確認したのか
    • 当該事業者は何を根拠に何を判断できるのか(被災地の通信状況を把握しているのか)
  • 当該事業者からLINEさんにどういう返答が来たのか、それを踏まえてLINEさんはどう判断したのか

まともな電気通信事業者なら、今回のLINEさんからの確認依頼には「そんなことやってくれるな」と答える気がします。理由は熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方 - わかりやすいを参照。

というわけで、影響の考え方の着想も含めて人材不足の可能性は捨てきれない。

  • 3.電話網への悪影響まで考えが及ぶ人材は社内に存在するものの、その人材へ連絡を取る必要性を考えなかった

見解に関連事項が含まれず、否定も肯定もできず。

  • 4.その人材へ連絡を取ろうとしたが、連絡が取れず、スピードを優先して実施に踏み切った

見解に関連事項が含まれず、否定も肯定もできず。

  • 5.その人材へ連絡が取れ、実施すべきでないとしたが、何らかの判断(ほかに考えられるメリットのほうが大きい、等)により実施することとした

見解に関連事項が含まれず、否定も肯定もできず。

今ある情報だけでは、これ以上の考察は難しそうです。

せっかくなので、LINEさんの見解を考察

LINEさんは見解の中で、「(以下のような)注意点をお知らせできていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点」とおっしゃっています。

  • 災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点
  • LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限る

お知らせできていなかった理由が「考えていなかった」のか、「考えたけど適切に表現できていなかった」のかはわかりませんが、ここで今一度、施策実施時のアナウンス内容を見てみましょう。

LINEから固定電話・携帯電話にかけられる「LINE Out」機能で、日本国内の番号への発信を1通話最大10分まで無料化しました。家の電話やLINEでつながっていない方への安否確認にご活用ください

この文章を書いた方は、以下のどちらの意図で書いたものか、推測してみましょう。

  • 被災地から被災地外への安否情報の通知・連絡・報告に使ってほしい
  • 被災地外から被災地への安否情報の確認に使ってほしい

ちなみに自分には後者を意図しているのかな、と読み取りました。 もし自分の読み取ったとおりなのであれば、以下が「本当に実施前に行われた検討なのか?」「取材に対して後付け的に考えたものなのではないか?」という疑問が沸いてきてしまいますね。

本施策の実施判断は、LINE Outの通常利用率やこれまでの災害時の無料化実施時の利用増加率、被災地から被災地外へのLINE Out通話・発信については輻輳リスクが低いこと、PSTNのバックボーンを担当している事業者への事前確認、などを判断材料としましたが、最も多くの利用が想定される被災地外から被災地へのLINE Out通話・発信は、輻輳リスクを高めることは事実であり、輻輳リスクを最大限低減させるという点においては、考慮・配慮が充分ではなかったと認識しております。

その告知についても、災害掲示板やテキストメッセージが災害時における優先的なコミュニケーションである点、LINE Out利用は、緊急性が高い場合においても、繰り返しかけない、短い時間で終わらせる、被災地から被災外へのコミュニケーションに限るなどの注意点をお知らせ出来ていなかった点は、可否判断基準とあわせて反省する点、見直しを行うべき点です。

真偽は定かではありませんが、少なくとも自分にとっては、LINEさんに対する印象がぐっと改善するような発表ではありませんでした。

もしよければ、いいね・シェア・ツイート・+等お願いいたします。

熊本県で発生した地震時のLINEさんの対応にみる、災害時の通信のあり方

(2016/04/16 11:30追記) LINEさんから見解が出たので、それについての考察記事を書きました。熊本県で発生した地震時にLINE Outを一部無料化したLINEさんの見解とその考察 - わかりやすい

表記の件。

例によって技術者の立場からの記事ですが、今回は珍しくLINEさんの対応を批判しています。 LINEさんの行動の真意(とりわけ「営業的思惑の有無」)に興味がある方は多いと思いますが、この記事では扱いません。

目次

結論

  • LINEさんの「LINE Out 1通話10分まで無料」施策は、結果的に被災地の電話網の不要な負荷増に加担してしまった可能性が高い
  • 届出電気通信事業者とはいえ、電気通信事業を行う会社として、法の趣旨に反した非常に軽率な行動だったと言わざるを得ない

以下、もう少し具体的に考察していきます。 まずは事実の確認から。

LINEさんが、いつ、何をしたのか

※以下、災害時に取る行動として推奨されない情報が含まれます。記事として読み、災害時の行動の参考としないでください。

2016/04/14(Thu) 21:26頃

熊本県震源とした地震発生

2016/04/14(Thu) 22:21頃 (地震発生から約55分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

2016/04/14(Thu) 23:16頃 (地震発生から約1時間50分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

※誤解が広がらないように削除される可能性があるので、本文のみ以下に引用します。

LINEから固定電話・携帯電話にかけられる「LINE Out」機能で、
日本国内の番号への発信を1通話最大10分まで無料化しました。
家の電話やLINEでつながっていない方への安否確認にご活用ください。
#熊本 #地震 #拡散希望

以降、上記ツイートに返信が多数寄せられる。 その大半は「電話網に負荷を掛けることになる」ことを懸念した、批判的な内容。

2016/04/15(Fri) 01:50頃 (無料化案内から約2時間34分後)

LINEの公式Twitterアカウント「@LINEjp_official」が以下をツイート

[https://twitter.com/LINEjp_official/status/720655437729673216:embed]

※なぜか展開されないので引用

安否確認の連絡は、まず通信量の少ない災害伝言板やLINEトーク等をご利用ください。
https://t.co/GGBjQj7RRQ 
先ほどご案内したLINE Outは回線に負荷が集中する恐れがあるため、
緊急性が高い場合のみご利用いただくようご協力をお願いします。
#熊本 #安否確認

災害時に通信はどうあるべきか

そもそも通信ってどうやって成り立ってるんだっけ

通信は通信用の設備で成り立っていますが、通信用設備にはキャパシティ(許容量)があります。 「同時にx回線まで利用可能」とかですね。

キャパシティが高ければ機器は高価になりますし、逆に低ければ機器は安価になります。

稼働率(キャパシティに対してどれだけ利用されているか)を高くすると儲けがたくさん出ますから、通信会社としてはなるべく安い機器にたくさん通信をさせたいわけです。 ただ、ケチりすぎると通信がパンクしてしまうので、その通信設備に期待される通信量に応じて、適切なキャパシティの通信設備を用いています。

どういうときに通信が成り立たなくなるんだっけ?

通信設備の故障が一番わかりやすいですが、それ以外に「通信したい人の数が通信設備のキャパシティを超える」という状況が考えられます。 人気アイドルのコンサートチケット発売時刻とか、新年が明けたし瞬間とか、今回みたいな災害発生時の安否確認とかで発生します。

通信したい量が通信設備のキャパシティを超えると、通信設備がパンクしてしまいます。専門用語では輻輳(ふくそう)」といいます。

輻輳すると何が起きるかというと、「使える人の数がキャパシティを大きく下回る」ことになります。 不思議ですね、キャパシティに近い性能くらいは出てほしいんですが、そうではないんです。

ところで輻輳が起きたとして、そこで行えなかった通信はいろんな内容がありますよね。 災害時にどんな通信があるのか。

  • 普通の日常的な通信
    • 災害があろうが無かろうが、行われている通信
  • 安否確認
    • 心配だけど、この通信ができないことが原因で人が死ぬことは無い
  • 救助要請(119番
    • この通信ができないと、それが原因で助けられた命が助けられないことがある
  • 二次被害予防のための警察・行政機関等への通信
    • この通信ができないと、それが原因で新たに命の危機を生むことがある

災害時、どの通信が優先的に扱われるべきか、こうやって並べると誰でも簡単に判断できますよね。

輻輳を防ぐために、誰が何をするのか?

さて、本題に近づいてきました。 通信設備を守るために、誰が何をするか。

通信事業

一番の主役です。NTT東西さんとか、ドコモさん、KDDIさん、ソフトバンクさん、あとNTTコミュニケーションズさんあたりが対象ですね。 彼らは「重要通信」を守ることを目的に、輻輳を防ぐ」をために「必要最小限度の通信の制限」を行います。 これにより、重要通信以外はキャパシティが逼迫している通信機器に到達しなくなります。 ちなみに重要通信を守るための通信の制限は、電気通信事業法において彼らに課された「義務」です。

通信利用者

電話やLINEを使っている我々ですね。どうあるべきか、でいうと、

  • 救援要請等は遠慮なく行う
  • 重要通信の邪魔になるような通信は極力行わない

これに尽きると思いますが、これって具体的に何をどうすればいいのか、難しいですよね。 考えるための材料を少し整理してみます。

  • 輻輳しにくい通信手段を選ぶ

電話(通話)よりSMS(ショートメッセージ)、SMSよりインターネット(LINEとかSkypeとかTwitterとかFacebookとか)です。

「インターネット」は、「(電話やSMSが使う)電話網」より通信のキャパシティが大きいケースが多いですが、例えばインターネット用の通信線が切れた場合など、インターネットも輻輳するときは輻輳します。以下も是非参考にしてください。

  • 少ない通信量で用件を済ます

動画より静止画や音声、静止画や音声よりテキストメッセージが通信量が少なく、通信設備にやさしいです。 また、動画や音声の再生は携帯端末の電池をテキストよりも多く消費します。 なるべくテキストメッセージがいいでしょう。

  • うまく通信できないときは

輻輳している可能性があります。 短時間に何度も再挑戦しようとすると、輻輳の復旧を遅らせてしまうことになります。 電話にせよSMSにせよインターネットにせよ、うまく通信できないときは少し時間をおいてから再挑戦しましょう。それだけで輻輳の回復が早くなります。

LINEさんの対応はどうだったのか

LINEさんは「LINE Out」という機能を条件付きで無料化し、安否確認にLINE Outを使うように推奨していましたね。 「LINE Outは」調べたところ、「(インターネットにつながった)LINEが動いているスマホと電話網の間で電話をさせる」機能のようです。

みんながLINE Outで安否確認を行ったらどうなりますかね。 今回の件で言えば、熊本の電話の通信設備にLINE Outから通信が流入することになります。

今回、熊本で輻輳が発生したかどうか、通信事業者が重要通信を守るための通信制限を行ったかどうかは私は調べていませんが、どちらも発生しない・行われない方がいいのは当たり前です。

LINEさんの今回の対応は、輻輳の発生や通信制限の発動を加速させる方向の対応でした。 これはとてもよくない。

電気通信事業の観点から見るLINEさん

LINEさんは「電気通信事業法」の規程する「届出電気通信事業者」のようです。

linecorp.com

届出電気通信事業者A-20-9913

LINEさんの今回の対応は電気通信事業法上は違法ではないと考えます。 (詳細は要望がたくさんあれば書こうと思いますが、ややこしいのでとりあえず省略します。) ただ、法の趣旨に反した行為であったと考えます。以下、電気通信事業法の目的を引用します。

(目的)
第一条  この法律は、電気通信事業の公共性にかんがみ、
その運営を適正かつ合理的なものとするとともに、
その公正な競争を促進することにより、
電気通信役務の円滑な提供を確保するとともにその利用者の利益を保護し、
もつて電気通信の健全な発達及び国民の利便の確保を図り、
公共の福祉を増進することを目的とする。

地震発生の直後から自分たちにできることを考え、 地震発生の1時間50分後にアクションを起こしたその迅速さにはとても敬意を表します。

ただ、今回の施策は重要通信の確保を妨げかねない軽率な行動だったと思います。 しかも、LINEさんは(届出電気通信事業者とはいえ)電気通信事業者でした。

届出電気通信事業者は、簡単に言えば「電話ほど品質が求められない、ライトな事業者」です。 (詳細は電気通信事業法を読んでいただければと思います。) 電気通信がどうあるべきかについて、電話屋とインターネット屋(老舗大規模ISPを除く)では向き合い方が全く違います。 奇しくもLINEさんは、「自社がいかに電気通信事業を理解していないか」「届出電気通信事業者の中には、電気通信事業法の目的すら理解していない事業者が存在する」という二つの事実を明々白々にしてしまいました。

LINEさんの今後の改善に大いに期待したいと思います。

(2016/04/16 11:30追記) LINEさんから見解が出たので、それについての考察記事を書きました。[http://wakariyasui.hatenablog.jp/entry/2016/04/16/112037:title]

よろしければシェア・ツイート等お願いいたします。

以下、うんちく

電話屋とインターネット屋の通信品質に関する考え方の違い(LINEさんに同情する方向の技術的考察事項)

例によって推測を含みます。

インターネットにおける通信品質の考え方と、電話における通信品質の考え方にはかなりギャップがあります。 電話は(輻輳が起こる通信設備の役割にもよると思いますが)

これが基本的な対応方針です。

一方のインターネット(とりわけ、コンテンツ屋やアプリ屋)はというと、

  • 増強

これが基本的な対応方針です。なぜか。

  • 輻輳とか通信制限で発生する機会損失による経済的ダメージが大きい
  • 増強が電話に比べて容易・安価

つまり、コンテンツ屋・アプリ屋には「通信を区別」して「特定の通信を守る」という文化が希薄なんです。
(実効的かどうかはさておき、インターネットにおいて通信を区別したり特定の通信を守る技術はもちろんありますし、通信屋寄りのインターネット屋はそれらを駆使して、相応の価値を社会に提供しています。)

また、電話(VoIP)で発生する通信量は、彼らが扱う総通信量に比べたらゴミみたいなものです。 ちょっと(数万)呼が発生しただけで通信設備に影響が出るなんて、というのが、 今回施策のゴーを出した方の本音かもしれません。
(少なくとも電気通信事業法に明るい方が意思決定に携わっていらっしゃれば、ゴーが出ることは無かったでしょう。)

ソフトバンクさんの例

日本には、「大規模災害発生時における公衆無線LANの無料開放」を行う仕組みがあります。

[http://www.wlan-business.org/customer/introduction/feature/00000japan:title]

公衆無線LANの関連事業者が主体的に行っています。

ほかの事業者さんも無料開放を開始しているかもしれませんが、ソフトバンクさんの記事が最初に目についたので、一例として。

[http://www.softbank.jp/corp/group/sbm/news/info/2016/20160415_01/:embed:cite]

災害時にインターネットが使える(結果的に電話への負荷も軽減される)ことが重要であることは東日本大震災の教訓でもあり、 ソフトバンクさんをはじめ、きっちり運用されている通信事業者の方々に敬意を表します。

東日本大震災時の例

電話屋以外でも、災害時等に通信の品質をしっかり考えている企業は存在します。

[http://morioka.keizai.biz/headline/873/:embed:cite]

電気通信事業についてIIJさんとLINEさんを比べるのは酷ですが、 法の趣旨をきちんと理解しているIIJさんとLINEさんの対応の違いには、学ぶところがありそうです。

 ITソリューションを手がける「インターネットイニシアティブ(IIJ)」(東京都千代田区)は3月16日、
東日本大震災の発生を受け、岩手、宮城、福島各県の自治体のミラーサイトの無償提供を始めた。

 各自治体へのアクセス集中による負荷を緩和するのが目的で、
地震発生後、閲覧が困難だった自治体ホームページが見やすくなる。

ミラーサイトは現在、市町村のみ公開されており、順次全ての自治体へ広げていくという。

 同社広報担当者によると
「福島県のように、ミラーサイトを構築する前に既にサーバーダウンしてしまったところもあり、
全ての自治体をカバーできていない。特に県はまだできていないが、
各県の広聴広報課と連絡が取れ次第、順次公開していきたい」
と話している。

 ミラーサイトは、同社が今月14日から無償提供しているクラウドサービス
「IIJ GIOホスティングパッケージサービス」を利用したもの。
設備が関西にあることから、東北や関東地域の電力不足の影響も受けにくいとしている。

この記事の改定履歴

  • 2016/04/15(Fri) 12:20頃 ソフトバンクさんの例を追記、一部目次構成を変更

kvmでストレージパスを変更してのライブマイグレーション

やりたいことがタイトルで表現できているかどうか謎ですが、概要は以下の通りです。

目次

何をやりたいのか

  • KVM Host A(以下HA)からKVM Host B(以下HB)にGuest X(以下、GX)をライブマイグレーションしたい
  • その際、ストレージパス(ディスクパス)を変更したい
    • 例えば以下のようなケース
      • HAではGXのストレージが/path/to/gx.imgだったとする
      • HBではGXのストレージを/path/to/gx2.imgとしたい、というケース
    • ストレージパスが変わる、ということはつまり(ほとんどの場合は)「共有ストレージを用いたライブマイグレーションを行わない」ということ

上記ができると何がうれしいのか?

例えば

  • iSCSIベースのストレージからファイルベースのストレージに切り替える
  • 冗長化のためにdrbdを噛ませたい

とか。

アプローチ

  • ストレージを丸々コピーするマイグレーション方式を利用する(virshの--copy-storage-allオプション)
  • 移行先で有効になるxmlを指定する(virshの--xmlオプション)

具体的な手順

冒頭の「何をやりたいのか」の例を当てはめつつ説明します。

1. 移行先ホストで、移行先ストレージを用意する

例では以下になります。

  • HB上で/path/to/gx2.imgを用意する

2. 移行元ホストで移行対象の仮想マシン定義を出力、移行先用に書き換える

例では以下になります。

  • HA上でGAの仮想マシン定義をdumpする(virsh dumpxml 仮想マシン名 > ダンプ先ファイル名)
  • 移行先用に仮想マシン定義を編集する(上記の「ダンプ先ファイル名」で指定したファイルを編集する)
    • 編集内容は「ストレージパスの書き換え」
    • 例えば以下のようなこと
(snip)
 <domain type='kvm' id='X'>
 (snip)
   <devices>
     (snip)
     <disk type='block' device='disk'>
       (snip)
-      <source dev='/path/to/ga.img'/>
+      <source dev='/path/to/ga2.img'/>
       (snip)
     </disk>
   (snip)
   </devices>
 (snip)
 <domain type='kvm' id='X'>

ここでは「ダンプ先ファイル名」をga.xmlとします。

3. マイグレーション

例では以下になります。

コマンドにするならこんな感じ

HA# virsh migrate --live --persistent --copy-storage-all --verbose --xml ga.xml GuestA qemu+ssh://HB/system

これでライブマイグレーションできるはず。

注意点

いろいろ問題点があります。

  • 長い時間、ストレージとネットワークに負荷がかかり続ける
    • ストレージ内容をネットワーク経由で全部コピーすることになるので、シンプルにやるならこの特性はやむなし

こんなもんだろうか…。

しかしとりあえず、時間がかかっても「止めずに、別ストレージパスに移行できる」というのはかなりメリットな気がする。