【続報】運営するサーバのIPをアドレス変更してから「変」なことが続いています

昨年12月に投稿した記事になりますが、 Webサービスを運営するサーバを別のクラウドサービスに切り替えたあたりから、Search Consoleに表示されるインデックス数が激減した記事を書きました。

blog.boost-up.net

今日は久しぶりにその続報をお伝えします。

サイトマップのインデックス数はなんとゼロ!!

前回報告時には約4,000ページの10%程度まで落ち込んでいましたが、 その後も減少が止まらず、ついにはゼロになってしまいました。 本当にゼロです。1件もありません。

ほぼ時を同じくして、完全SSL化の対応も行ったため、 Search Consoleには以下2つのプロパティを登録していますが、いずれも完全にゼロです。。

http://上場企業サーチ.com https://上場企業サーチ.com

サイトマップにはきちんと約4,000件が送信済みとして認識され、直近では2018年5月19日に処理されています。 インデックスエラーもゼロです。

検索アナリティクスは復活!!

諸々の変更前には一日あたり5,000~10,000PVだったのが、一時100ページ程までに落ち込んでいましたが、 こちらは徐々に増加に転じ、Search Consolの表示上も完全に元に戻りました。

変更前サーバからのIPベースの被リンクは若干残ってる

以前の記事で書いた通り、サーバの切り替えの仕方に起因すると思われる謎の被リンクが大量に残っていた件は、 Googleの被リンク否認ツールに登録して以降徐々に減り始め、いまでは殆どなくなりました。

ただ、ゼロにはなっていないので、影響が完全に排除されたのかどうかはわかりません。

結局実害が出ているのか?

前回の記事を投稿してからここまで約半年間、大騒ぎしなかったことがすべてですが、 Google Analyticsに見る実際のアクセス数は完全に元に戻っており、 Organic Search経由の流入比率も変更前後で大きな差異は出ていません。

Search Consoleでサイトマップの情報が見れないこと以外は今のところ不自由も感じていません。

まとめ

ということで、問題が解消したらまた更新したいと思いますが、 前回の投稿時に書いた「大変なことが起きている」は取り下げさせていただき、 タイトルを「変なことが続いている」としたうえで、この件については当面静観したいと思います。

学校教育は洗脳であると主張する堀江さんの本を読んでみた

すべての教育は「洗脳」である~21世紀の脱・学校論~ (光文社新書)

堀江さんは、学校は従順な国民を量産するための洗脳機関であり、意欲や興味に対して行動するというシンプルな行動原理に心のブレーキを付ける場所でするとの考えから学校教育を否定しています。

一方で、没頭することの重要性を強調しており、その観点では勉学自体を否定しているわけではありません。 むしろ、自らの興味と意欲で経験したものは例え遊びからであっても学びに繋がり、その経験の中に無駄になるものはない、そう仰りたいのではないかと感じました。

型を持ち出す時点で分かっていない、と叱られそうですが、感覚と意志を重視し、やりたいとこもやりたくないことも自分で決める事を良しとする、モンテッソーリ教育に似た発想のように思います。

個人的にも社会人としてある程度経験を積んだ今、改めて学校教育を振り返ると、かなりの部分で共感出来ることがあります。

殆ど全ての人間が将来、国家、企業あるいは何らかのコミュニティ・集団に所属する一員である事を念頭に置くと、集団生活の中で最低限の常識を学ぶ環境としての学校には重要な存在意義があると思います。 その一方で、学校が教える授業は言葉の通り、授けるスタンスが背景にあるわけですが、確かに授業で教わった諸々、特に古典や歴史などはある解釈の集大成ですし、道徳教育もその背景にあるのは善悪や価値観に対する一面的な解釈を題材にしており、良い成績・評価を得るために出題意図を推し量る思考回路が知らず知らずのうちに出来上がっていたように思います。

私自身、アイディアを行動に移そうとしたことか幾度となくありましたが、その度にアクセルと同じくらいブレーキを考える論理フレームワークが働いてしまい、時間とともに熱意を冷まし、固化してしまうか第三者が先に行動に移してしまうことが何度もありました。

良書を読んだからと言って、行動原理や思考回路を急にガラガラポンする事も簡単ではないのでしょうが、心のブレーキの存在を意識して、やらない理由・言い訳を作らないよう自分のモチベーションを上げていこうと思います。

年明けからの仮想通貨の状況について、去年の主張を振り返る

f:id:boost-up:20171222203243j:plain

2018年に入って仮想通貨が軒並み暴落し、今も不安定な状況が続いています。

そんななか、先日はコインチェックからNEMが盗まれたという事件も発生し、ただでさえ怪しいと思われることが多かった仮想通貨が益々不審がられるのに十分な状況です。

以前の記事で、仮想通貨の本質的な価値はゼロであることを書き、また別の記事では、年末にポートフォリオを組み替えることのリスクを書きました。

blog.boost-up.net

blog.boost-up.net

国税庁の見解では、ポートフォリオの組み替えは利益の実現となりますので、年末にポートフォリオを組み替え、年明けの暴落に直面した方の中には、2月16日から始まる所得税の確定申告シーズンを控え、納税資金なき利益に頭を抱えている方もいらっしゃるかも知れません。

そこに来てNEMの事件の発生により、コインチェックに預けている仮想通貨は引出しや送金が停止になってしまっているため、コインチェック一本でやっていた方は利益の確定すら許されず、残った仮想通貨を処分して納税することも難しい状況です。

税金に関して、普通に考えれば仮想通貨投資家に対してこの件で救済措置が取られる可能性は限りなくゼロに近いと思われます。

租税債務は自己破産をしても消滅しません。

確定申告をしない場合には無申告加算税を含む厳しい措置が取られる可能性があるので、まずは確実に確定申告を行うようにしましょう。

2017年はもう終わってしまいましたので、残念ながら今から利益を調整することは出来ませんが、 国税には一定の要件を満たす場合に納税の猶予が認められる場合がある「換価の猶予」という制度が存在します。

[手続名]換価の猶予の申請手続|納税証明書及び納税手続関係|国税庁

https://www.nta.go.jp/shiraberu/ippanjoho/pamph/sonota/itiji_leaflet.pdf

厳しい現実ですが、利益を確定させるときは納税まで意識することが投資の鉄則ですね。

Webサービスの障害対応を終えて、、、

f:id:boost-up:20180124130503j:plain

暫く更新が滞ってしまいました。

前回の記事で、SCDB JAPANに年末からBingクローラーのアクセスが急増し始めた事と、それによってRedisに障害が起きたことを書きました。

blog.boost-up.net

Redisの障害は正月のうちに何とか対応を終えたのですが、その後もBingクローラーのアクセスは増え続け、日に20万アクセスを超えるようになりました。

クローラーのアクセスが増えることは、将来的にサーチエンジン経由での流入に繋がる可能性が高いので、基本的に嬉しいのですが、 実は年明けにRedisの件の他にもう1件、原因不明の障害が発生し、つい先日まで対応にかかりきりになっていました。

今回の障害は2台で負荷分散しているWebサーバがほぼ同時に通信を受け付けなくなるというもので、 障害が発生するとhttpだけでなくsshも受け付けなくなります。 他方、pingは通りますし、サーバ自体は活きておき、クラウドサービスのコンソール経由ではログインも出来ます。 tcpコネクションやローカルポートの枯渇も疑いましたがこちらは問題なさそうです。

困ったのは各サービスのログにもOSのログにも、それらしいエラーが何も記録されていないことでした。

決して負荷が高くないときでも2台が同時に通信不能となることから、Webサーバ側ではなく、ネットワーク周りかバックエンドのDBサーバ側に問題がある可能性も疑われる状況です。

ただ、バックエンドのサーバの多くは上場企業サーチと共有しているのですが、その上場企業サーチにはまったく影響が出ていないため、バックエンド側の可能性は低いと思われました。

それでも一応一通り各サーバのログは調べたところ、障害発生時に一回だけ、DB側との接続が切れたログがありました。

そこで、SCDB JAPANと上場企業サーチのDB接続周りの設定を比べたところ、1箇所だけ異なる点が見つかりました。

上場企業サーチはDBサーバに直接繋ぎに行くようになっている一方、SCDB JAPANは冗長化を試行錯誤する過程で、仮想ルータのロードバランサを経由してDBに繋ぎ行くようになっているのですが、改めて見るとグローバルIPを指定してしまっています。 本来なら内部ロードバランスには仮想ルータのプライベートIPを指定すべきなのかもしれません。

そこで、上場企業サーチと同じように直接接続に戻して再起動をかけたところ、めでたく現象が発生しなくなりました。

上場企業サーチに影響が出なかった理由は継続調査中ですが、何とか年末から続いていたゴタゴタも収束しました。 怪我の功名でサービスの安定性も向上させることができ、ワンステージ上のトラフィックにも対応できる体制が整ったと信じています。

今年こそはサービスの成長と躍進に向けて進んでいきたいと思います。

日々勝負

<解決済み>Bingクローラ急襲によりサーバが応答不能に。。。

2018年最初の投稿になります。

早速ですが、年始からSCDB JAPANにちょっとした事件(障害)がありました。 正月休みを返上して(というのはだいぶ大袈裟ですが)原因調査と対応に当たりましたのでその一部始終を記載します。

Bing襲来!?(Welcome!!)

f:id:boost-up:20180105215551p:plain

上はBingウェブマスターツール上から確認できるBingクローラーのアクセス状況です。

従来は1日当たりのクロール数は概ね数千から2万ページ程度だったのですが、 12月28日あたりからアクセス数が急増し始め、1月2日~本日まで10万ページ/日を記録し続けています。

1月1日までは「いよいよXデーが近いか」と期待して見守っていたのですが、1月2日の夕方に事件が起きました。

Redisサーバと正常な通信ができない事態が発生

blog.boost-up.net

上記の過去記事で、冗長化の話を書いたとき、 SCDB JAPANは100倍のアクセスが来ても耐えられると調子に乗って宣言していたのですが、 恥ずかしながら、たかが10倍程度のアクセスでまさかのサービス停止に追い込まれる障害を発生させてしまいました。

Webサーバの負荷

SCDB JAPANはフロントにLVSサーバを配置し、WebサーバはH2Oサーバ2台構成でロードバランシングを行っています。 Bingからのアクセスが急増し始めた後の1月1日の時点でも、CPU使用率はまだ一桁台、メモリ使用率もまだ50%を切る状況で十分に余裕がありましたので、この程度のアクセスが翌日のサービスダウンに繋がるとは初夢にも思いませんでした。

500エラーの急増とOOMの多発

Webサーバの負荷が十分低いにも関わらず、1月2日の18時頃から500エラーが急増し始めました。 実際にブラウザでアクセスしてもWebページが表示されず、一人緊急対策会議を始めました。

unicornのログ

まず調べたのはアプリケーションサーバであるunicornのログです。 恐れていた通り”FATAL”という致命的なエラーが発生してしまっています。

F, [2018-01-02T18:10:50.417908 #82334] FATAL -- : [6849ed35-e5bf-472e-8bf1-3da7413842a2] ActionView::Template::Error (OOM command not allowed when used memory > 'maxmemory'.):

このエラーメッセージをヒントにググってみると、先人の経験から、どうやらこのエラーはRedisに関して発生している可能性が高いことが分かりました。

qiita.com

SCDB JAPANではキャッシュサーバとアクセス数集計サーバにRedisを使っており、 リソースはまだ最低限しか割り当てていませんので、十分に可能性が考えられました。

キャッシュサーバ用のRedisとアクセス数集計サーバのRedisは別サーバで運営しているのですが、 普段、アクセス数集計サービスの方が数倍の負荷がかかっていることを見ていたこともあって、先入観からアクセス数集計サービスの方が原因と思い込んでしまい、対応に時間を要する羽目になりました。

先人の経験を参考に同様の対策を施してサービスを再起動しても減少は解消せず、一旦手探り状態となりました。

Redis以外の原因を疑う

Webサーバ越しにアクセスすると500エラーが頻発する状況の中、本番環境上のRails consoleを使ってRedisへの疎通を確認すると、キャッシュサーバ、アクセス数集計サーバともに、全くエラーなく接続できる状況だったため、Redis以外に原因がある可能性も否定できませんでした。

LVSサーバのログを調べたり、ロードバランサ越しのアクセスではなく、直接Webサーバに接続するなどして挙動を見ていましたが、LVSやWebサーバ自体のログには問題となりそうな異常は見つけられませんでした。

TCP接続エラーを疑う

解決のヒントを探して色々なブログ記事などを見ている中で、一つ気になる情報を見つけました。

dsas.blog.klab.org

この記事はmemcachedに関する記事なのですが、SCDBのredisもキャッシュサーバを担っていることから、もしかしてと思い調べてみることにしました。

キャッシュサーバのsomaxconn(TCPソケットが受け付けた接続要求を格納するキューの最大長)の設定値を調べてみます。

$ sysctl net.core.somaxconn
net.core.somaxconn = 128

、、、自らの知識不足に情けなさを感じると同時に、一筋の光が差した思いがしました。

念のため、netstatも見てみます。

Tcp:
    232712 active connections openings
    2956 passive connection openings
    13370619 failed connection attempts
    90 connection resets received
    5 connections established
    59221754 segments received
    39087217 segments send out
    10131 segments retransmited
    0 bad segments received.
    659 resets sent

上から3つ目に13370619 failed connection attemptsとあり、一千万を超えるTcp接続要求が失敗していることが判明しました。 この時点で疑惑は確信に変わりました。

somaxconnの設定値を変更する

早速sysctlの定義ファイルを作成し、somaxconnの設定値を変更します。 今回は128→4096に増やしてしばらく様子を見ることにします。

1.定義ファイルの作成

vi /etc/sysctl.d/custom.conf

net.core.somaxconn=4096

2.定義ファイルの反映

$sudo sysctl --system
(略)
* Applying /etc/sysctl.d/custom.conf ...
net.core.somaxconn = 4096
* Applying /etc/sysctl.conf ...

設定変更が反映されました。

3.Redisの再起動

$ systemctl restart redis.service

藁にも縋る思いでWebサーバ越しのアクセスを確認すると、待望の「http status 200」の文字が並び始めました!!

その後の経過

1月3日に対策を行って以降、この記事を書いている1月5日時点までにはその後問題は起きていません。 障害によってクロールペースがダウンすることが懸念されましたが、BingにもGoogleにも今のところ大きな変化は起きていないようです。

ただ今回設定した値の妥当性についてはまだ手探りですので、もしかしたらまたいつか同じ事象が起きる可能性があります。

実アクセスが原因でこの手の障害が起きてしまうと色々と損失が大きいので、正月という閑散期にクローラーが原因で起きたことは寧ろ非常にラッキーだったと言えると思います。

今回のようにクローラーではなく実アクセスを伴うようになって来ればサーバを増強する予算もついてくると思いますので、 財布と相談しながら早め早めに手を打てるように、今年も頑張りたいと思います。

niceなクラウドマイニングでほんの少しだけ幸せになる方法

f:id:boost-up:20171225232601j:plain

クラウドマイニングって儲かるの?

儲かりません!

クラウドマイニングって元が取れるの?

無理です!!

じゃあこの記事は何なの?

とても限定的な状況下ではありますが、クラウドマイニングが役に立つシーンを思いついたのでその共有です。 過度な期待をしないでください。条件に合う境遇にある極一部の人が”ほんの少し”だけ幸せになれるかも知れない方法です。

まだ実証実験が出来ていませんので効果はあくまで試算であることと、この方法によってサーバにネガティブな影響が出ない(または無視できる)と言えるかどうか、正直まだ自信がありませんのであくまでその前提で書きます。

それと、この方法は悪意を持って使うと周囲に大きな迷惑をかける可能性がありますので、絶対に悪用しないでください。 多分私が書かなくても早晩誰かが同じような記事を書くでしょうし、誰も書かなくても誰かがこれと似たような方法を使って悪事を働くケースが出てくると思います。

今回あえてこの記事を書くことで、こんな方法もあるんだということを広く知ってもらい、「監視による抑止効果」を期待したいと思います。

この方法でほんの少し幸せになれる人

  1. 自分でクラウドサービス(基本的にはIaaSかVPS)を契約している人
  2. サーバリソースに十分な余裕があること
  3. サーバが少しくらい遅くなっても大目に見れること

この3条件をクリアできる環境にいる人自体それほど多くないと思われます。

一方、悪意ある立場で考えると、1.はクラウドサービスの管理者である人、3.はそれほど重要な役割ではないサーバであるか、それを問題にならないように出来る立場にいる人は、不正を働く動機を持った時にはそれが実行できるリスクがある人かも知れません。

この方法を悪用すると、最近問題になっている、悪意のあるjavascriptを送り込んで他人のマシンにマイニングをさせる方法と非常に近い結果が得られてしまいますので、繰り返しになりますが世の中に啓蒙することで「監視による抑止効果」を期待したいと思います。

別記事でminergateについて書きましたが、この方法は私自身が好奇心からminergateを使ってみて、思いついた方法です。 blog.boost-up.net

今回はminergate前提に書きますが、おそらく他のマイニングプールでも同じような方法を使うことができると思います。

幸せになるための事前準備

今回はCentOSを前提にしますが、この方法を使うためには3つのコマンド(プログラム)が必要になります。

minergate-cli

minergateによるマイニングをコマンド実行するためのプログラムです。 ダウンロード方法はここでは触れませんが、Minergateの公式サイトから誰でも簡単に入手できますので、「自分が契約する」サーバ上で利用できる状態にしてください。

nice

プロセスの優先度を指定するコマンドです。 通常Linuxのプログラムはnice 0という優先度で動きます。nice値は-19が最も優先度が低く、20が最も優先度が高いことを意味します。

cpulimit

プロセスに割り当てるCPU使用率を制御するコマンドです。 例えば、cpulimit -l 10 <任意のコマンド>で実行すると任意のコマンドが使用するCPU使用率を10%までに制限することが出来ます。

ここまでで、そろそろ結果が見えた方もいると思います。

ほんの少しだけ幸せになるための魔法の呪文

あとはOS上で以下のコマンドを実行するだけです。

nohup cpulimit -l 80 nice -n 19 minergate-cli --user <minergateアカウントのメールアドレス> --xmr &

文章で書くと、「ログアウトしても中断しないバックグラウンド処理として、CPU使用率上限80%(適当に調整してください)かつ最低優先度でMonero(これは他の通貨でも良いです)の採掘を開始する」処理となります。

これにより、普段は概ね80%のCPU使用率を維持しながら採掘し、他のプログラムが起動されたときにはそちらにCPUを譲る動きが期待できます。

この発想のポイントは次の2点です。

1.固定費の一部回収を期待するものであること

クラウドマイニング単独では投資回収ができないことは所与として、サーバリソース、特にCPUリソースに空きがある場合に、その一部でマイニングを続けることでサーバ利用料の一部だけでも回収するという考えです。

2.他の処理を優先する控えめな実行であること

この処理を実行するサーバは本来別用途で存在しているサーバですので、儲からないクラウドマイニングのために本来のサービスが疎かになっては困ります。

そのため、nice値を最低にすることで他の処理が起動されたときには、そちらを優先するように予め優先度を最低に指定しています。 ただそれだけだと、minergate-cliがCPUを使い切って監視に引っかかる状態になってしまったため、cpulimitを併用することで高稼働にならないよう制御しています。

クラウドマイニングはただでさえ儲からないので、この方法で回収できる金額はそれこそ微々たるものですが、塵も積もれば効果は期待できると思います。

どれくらい幸せになれるのか?

皮算用ですので、「どれくらい幸せになれそうなのか?」が正しいかも知れません。

例えば私が使っているIDCFクラウドのLight.S1プランだと、毎月の使用料は例えば648円(仮想マシン200円、ルートディスク300円、データディスク100円、消費税8%として48円)です。

このサーバ上で今回の採掘コマンドを実行した場合のハッシュレートはだいたい6.5-10H/sです。

ハッシュレートに対してどれくらいの収益が期待できるかは、↓のサイトの値を信用すると一か月あたり0.001914XMRとなります。 www.cryptocompare.com

これに乗じるMoneroのレートは1XMR=39,273.142958円(2017年12月25日のある時点)とすると、計算上は75.17円/月の収入が得られることになります。

最近の仮想通貨はボラティリティが非常に激しいので全く参考にならないかも知れませんが、 648円でサービスを提供しながら75.18円が得られるということは、サーバ利用料の約11.6%がマイニングで回収できるということになります。

サーバ1台では微々たる金額ですが、私は仮想サーバを10台以上契約していますので、マイニングによって得られる資金で仮想サーバを1台追加できることになります。

この程度で幸せを感じている場合でないのは自分でも良くわかっております。

そうだ、クラウドマイニングを始めてみよう!

f:id:boost-up:20171225221155j:plain

仮想通貨のマイニング

仮想通貨のマイニングは発電コストが出来るだけ安い環境で、高性能なASICやGPUを用意して全力投球し続けるというのが定石になっており、日本のように発電コストが高い国とアイスランドのような地熱エネルギーが豊富な国とでは限界利益率が違いすぎて勝負にならないと言われています。

ネット上ではAWSなどのクラウドサービスを使ったマイニングの採算を検証したブログ等が多数ありますが、いずれも採算には程遠い結論になっているようです。

それでもマイニングで利益を目論む一部の悪意ある人々は、ついに他人のマシンリソースを勝手に使って自分のためにマイニングをさせるスクリプトをバラまいており、ここ数日新聞各紙でも報道されるようになりました。

仮想通貨のマイニングに参加する方法

仮想通貨のマイニングはインターネットにつながるパソコン等を持っている人であれば、基本的には誰でも始めることができます。

ただ、仮想通貨のマイニングを一人でやること(ソロマイニング)は現実的にお勧めできません。 冒頭でも書いたように、仮想通貨を効率よく採掘するためには「電気代を抑え」、「高性能な処理機材」が必要ですが、 個人で用意できる範囲には限界がありますし、実際マイニング市場では「マイニングプール」と呼ばれる集団採掘が多数派となってきています。

「マイニングプール」にはマイニングファームと呼ばれる採掘専門会社や、個人のマイナーなどが多数参加し、「ハッシュレート」という指標で計算・評価されるそれぞれのマシンリソースを拠出する形で、一つの巨大な採掘力を生み出しています。 各マイニングプールとも自分たちのハッシュレートを高めるべく参加者を募っており、こうした組織力にソロマイニングで対抗することは無謀とも言えます。

マイニングによって得られる経済的価値を度外視して、マイニング行為自体に興味がある場合以外は、おとなしくマイニングプールに参加する方法を選択した方が良いと思います。

マイニングのイメージが湧かない方は、初心者でも簡単にマイニングを始めることができるminergateを始めて見ることをお勧めします。

minergate.com

minergateでは自分が採掘に参加したいときだけマシンリソースを拠出することが簡単にコントロールできますので、 イメージと違う、儲からないなど、止めたくなったらいつでも止めることができます。

minergateの始め方

ここではアカウントの解説方法とGUI版のクライアントソフトの入手方法を紹介します。

minergateアカウントの解説

minergateのWebサイトに行くと下の様な画面が表示されますので、 右上の「Sign up」をクリックします。

f:id:boost-up:20171225215446p:plain

続いて、メールアドレスとパスワードを入力し、「私はロボットではありません」にチェックをしたら「Sign up & Start mining」をクリックします。

f:id:boost-up:20171225215658p:plain

たったこれだけでアカウントの開設が完了しました。 日本の仮想通貨取引所に口座開設するときのような本人確認資料の提出などは一切求められません。

クライアントソフトの入手方法

minergateを使ったマイニングはクライアントソフトを使わない(CUI版)とクライアントソフトを使った(GUI版)がありますが、 今回はパソコンに詳しくない方がより簡単にマイニングを体験することを目的としていることから、GUI版を使った例を説明します。

minergateのトップページに戻り、画面右側にある「Download & Start Mining」をクリックします。

f:id:boost-up:20171225214413p:plain

使っているパソコンのOSを選ぶ画面が出てきますので、自分が使っている/使いたい環境を選んでください。 少し待つと、今アクセスしているパソコンに最も適した環境に絞り込み表示されます。 使いたい環境が決まったら、「Get It」を押してクライアントソフトをダウンロードしてください。

f:id:boost-up:20171225214325p:plain

ダウンロードしたファイルを実行するとアカウント認証画面が表示されますので、 先ほど登録したメールアドレスとパスワードを入力し、「Login In & Start Mining」をクリックしてください。

minergateのマイニングには「Smart Mining」と「Mining」の2種類がありますが、 「Smart Mining」の方をクリックすると、そのパソコンの性能から掘りやすさを判断し、最も効率が良い通貨を採掘するように自動設定されます。マルチコアのCPUやGPUを積んでいるパソコンの場合、マイニングに割り当てるコアの数を指定することが出来ます。

一方の「Mining」の方は自分で通貨と割り当てるコア数を指定する方法です。

いずれもクリック一つでマイニングを開始することができ、中止したくなったらいつでも終了させることが出来ます。