Azure App Service のメモリ使用率について

App Service プランの Basic 以上は使用可能メモリの上限が決まっている。 同じ App Service プラン上に複数の Web Apps などを載せて使用することが出来るが、これはつまり、同じインスタンスのメモリを食い合っていることに他ならない。

例えば 5 個の Web App リソースを B1 プラン (メモリ 1.75GB) の同一 App Service プラン上に載せて、それぞれに素の ASP.NET MVC アプリをデプロイした場合、それぞれの Web App でワーカープロセスが動作しているのであれば、App Service としては大体 60% 前後のメモリ使用率が発生する。

App Service のアプリ設定には「常時接続」項目があり、これを「オフ」にするメリットは何なのかと思うかもしれない。 常時接続をオフにした場合、一定時間 (20 分) 使用されないとワーカープロセスが自動で終了するが、恐らく、上記のようにあまり使われない複数のアプリを同居させた際に使っていないアプリのワーカープロセスを落とすことで、複数アプリ同居時の効率を上げるためのオプションなのかと思う。なので、アプリを 1 つしか使っていないのであれば、常時接続をオフにするメリットは何もないと思われる。

以下は、上述した 1 つの B1 App Service に 5 個の Web Apps を載せた時のメモリ使用率の例。

f:id:poke_dev:20190407015637p:plain

最初に 55% まで上がり、その後、アプリを追加するごとにメモリ使用率が上昇して一度 65% ぐらいまで上がっている。 その後また 55% まで下がったのは、常時接続をオフにした後、アプリの再起動を行い、強制的にワーカープロセスを落としたため。 そこからまた 60% まで上昇しているのは、それぞれのアプリにアクセスしてワーカープロセスが起動したため。

ワーカープロセスが起動していなくても 55% までしかメモリ使用率が落ちないと言うか、そもそも最初の時点で 55% に達しているのがやや不思議だが、どうやらこれは、純粋なアプリの使用率ではなく、土台の OS も含めた使用率らしく、その部分で 55% (= 約 1GB) 常にもっていかれている様子。

Azure App Service Memory Usage. Where to see full breakdown? - Stack Overflow

以下は、アプリでのワーカープロセス使用がない状態で、Basic プランを B1 (1.75 GB) -> B2 (3.5 GB) -> B3 (7 GB) に上げていった際のメモリ使用率の変化。

f:id:poke_dev:20190407024343p:plain

それぞれのプランでの最低使用率が、B1 (54%) -> B2 (33%) -> B3 (20%) と低くなっていくことが分かる。 このパーセンテージで計算すると、プランを上げた際に最低使用量も B1 (950 MB), B2 (1.16 GB), B3 (1.4 GB) のように増加しているため、アプリ以外のメモリ消費量はプランによらず固定というわけでもない様子。

それぞれのプランでアプリが使用可能な残メモリを計算すると、B1 (800 MB), B2 (2.34 GB), B3 (5.6 GB) となるので、 アプリで使用可能なメモリ量 のみにフォーカスすると、プランが上がるほどお得になっている (CPU やその他リソースの事もあるので、メモリだけで一概にお得度は判断できないが)。

どうせなので、Basic, Standard, Premium (V1) についても B1 から P3 まで順に切り替えていってアプリのワーカープロセスなし状態のメモリ消費状況を確認してみたが、Basic, Standard, Premium 間で特に差異はなかった。

f:id:poke_dev:20190407134219p:plain

1.75 GB 3.5 GB 7 GB
B1 (52%) B2 (33%) B3 (20%)
S1 (51%) S2 (33%) S3 (21%)
P1 (51%) P2 (35%) P3 (20%)

稼働中 Azure Web Apps に影響を与える操作について (再起動とか)

Azure ポータルでは Web Apps に関して色々と操作出来るが、その際の稼働中 Web Apps の挙動について説明。 確認はしていないが恐らく App Service レベルの話なので、Functions とかでも基本的な挙動は同じかと思われる。

ここでは ASP.NET MVC のプロジェクト作成時の状態を Free/Basic プランの 1 インスタンス Web Apps で確認している。 Basic についても「常時接続」設定がオフの場合は、本件の確認内容については Free と本質的に差異はないはず。

また、Basic 以上のプランであれば 2 インスタンス以上にスケールアウトすることが可能だが、スケールアウト時は仮想マシン自体が増加するので、挙動の差異は特にないはず(同じ挙動が全インスタンスで同様に行われるだけ)。

なお、セッション情報の格納先が既定の InProc となっている場合は、ワーカープロセスの再起動やリサイクルでセッション情報も失われるので、注意。

Azure Web Apps + ASP.NET の環境的なレイヤーについて

Azure Web Apps + ASP.NET は、IIS ワーカープロセスの上に、ASP.NET の AppDomain が作成されて、アプリが動作する構成をとっている。

その為、まず IIS ワーカープロセスの生成が必要で、その上で、AppDomain (= ASP.NET アプリ) を生成して初めてアプリが動作する。 操作によっては、ワーカープロセスごと再生成されたり、ワーカープロセスは変わらずに中の AppDomain だけが再生成されたりするが、それによってアプリが応答可能になるまでの待機時間が異なる(もちろん、ワーカープロセスからの再生成の方が時間がかかる)。

なお、InProc のセッション情報は AppDomain 側に用意されているようなので、ワーカープロセスの再起動だろうが AppDomain の再起動だろうが、InProc のセッション情報はリセットされる。

Web Apps のアプリ設定として「常時接続」の項目があるが、この項目がオフの場合は、アプリが 20 分間アイドル状態になった際に自動的に当該ワーカープロセスが終了させられるので注意 (恐らく、Azure ポータルで「再起動」を実行したのと同じ状態)。 稼働中のワーカープロセスがない状態でリクエストが来た場合は、ワーカープロセスの生成がまず発生するので、アプリが有効になってレスポンスが返るまでに時間がかかる。

AppDomain の切り替えの場合、ブラウザからのリクエストがエラーとなるタイミングはないようだが、ワーカープロセスの切り替えの場合はエラーとなるタイミングがある様子。

各操作時の挙動について

1 インスタンス、常時接続オンの状態で操作した際の挙動を簡単にまとめると、以下。

操作 再起動対象 備考
Azure ポータルでの「再起動」 ワーカープロセス WP 終了時、利用不可になるタイミングあり
ファイル日付更新 (デプロイ含む) AppDomain AppDomain 並行起動により、利用不可になるタイミングなし
Azure ポータルでのアプリ設定変更 ワーカープロセス WP 並行起動により、利用不可になるタイミングなし
スロットのスワップ - レスポンス準備整い次第ドメインスワップが行われるため、スワップ先が利用不可になるタイミングなし

注: 「利用不可になるタイミングなし」は、リクエスト元に 503 などアプリ管轄外のエラーが返らない事を指しているが、新しいアプリがどれぐらいでレスポンス可能になるかはアプリ次第なので、注意。 例えば、ASP.NET でプリコンパイルを行っていない場合などは、ワーカープロセスの再起動と同時にコンパイル済みのイメージも全て削除されて次回ページアクセス時に再度コンパイルが発生するため、エラーは返されないがレスポンスが返るまで非常に時間がかかる可能性がある。

各操作時の詳細な挙動は以下。

Azure ポータルでの「停止」

稼働中のワーカープロセスが落とされて、落とされた後にリクエストがあった場合も起動は行われない。 稼働中のワーカープロセスで処理中のリクエストが存在する場合は、そのリクエストが終わった後、ワーカープロセスが落とされる。

停止中にリクエストがあった場合は 1 が返されるが、停止完了した後は 2 のページが表示される。

  1. 「HTTP Error 503. The service is unavailable.」 (恐らく IIS のエラーレスポンス)
  2. 「Error 403 - This web app is stopped.」 (恐らく Azure Web Apps の既定のエラーページ)

常時接続オンの場合 常時接続オンの場合も、処理は同じ様子。

Azure ポータルでの「開始」

ワーカープロセスが起動可能状態となる(この時点で起動されるわけではない)。

初回リクエストが来た時点で、ワーカープロセスが起動されて、アプリの準備が出来次第、レスポンスが返される。

常時接続オンの場合 常時接続オンの場合は、リクエストの有無に依らず、開始実行後自動的にワーカープロセスが起動する。 また、ワーカープロセスの起動後に AppDomain も作成され、リクエストに即時応答出来る状態になる。

Azure ポータルでの「再起動」

稼働中のワーカープロセスが落とされて、Azure ポータルでの「開始」実行時と同じ状態になる。 なお、稼働中のワーカープロセスで処理中のリクエストが存在する場合は、そのリクエストの処理が終わった後、ワーカープロセスが落とされる。 再起動実行後、処理中のリクエストの完了待ちでワーカープロセスが終了できない状態で新たなリクエストが来た場合、新しいリクエストも既存のワーカープロセスでそのまま処理される様子。

再起動実行時にリクエストがあった場合、タイミングによっては以下のエラーが返されることがある。

「HTTP Error 503. The service is unavailable.」 (恐らく IIS のエラーレスポンス)

常時接続オンの場合 Azure ポータルでの「開始」と同様の動きになる様子。

bin フォルダ配下のファイル変更や、Web.config の変更 (Kudu から直接)

変更の検出は恐らくファイル更新日付。

稼働中ワーカープロセスはそのままで、中の AppDomain が変更後のアプリ用に同一ワーカープロセス内に新規作成されて、新しいリクエストを処理する。 なお、古い AppDomain がリクエストを処理中だった場合、そのリクエストの処理が完了した後に、古い AppDomain はシャットダウンされる(はず)。 古い AppDomain が処理中リクエストの完了待ちの状態で新たなリクエストが来た場合、新しいリクエストは並行して作成された新しい AppDomain で即座に処理される (Application_Start() にログをしかけて測定)。 一時的に新旧 AppDomain が共存する形となっているはずだが、画面などから確認するすべはない。

なお、完全にアンドキュメンテッドな内容だが、AppDomain リサイクル発生時に処理しているリクエストが存在した場合、処理中の全リクエストが完了して古い AppDomain がシャットダウンした直後に、新しい AppDomain が作成される(新しいリクエストがなかったとしても)。 逆に AppDomain リサイクル発生時に処理しているリクエストがない場合、新しい AppDomain が作成されるタイミングは、新しいリクエストが来たタイミングとなる。

AppDomain の切り替えに留まるからか、ブラウザから見ると新しい設定の準備が整うまで数秒程度の待ち時間は発生するが、利用不能な時間は発生しない様子。 なお、InProc のセッション情報は AppDomain 単位で持っているため、AppDomain 切り替えのタイミングでセッション情報もクリアされる。

常時接続オンの場合 常時接続オンの場合も、処理は同じ様子。

複数インスタンスが起動している場合 ストレージは全インスタンスが同じ場所を見ているため、ファイル変更は全インスタンスが同様に影響を受ける。

Visual Studio からの発行 (デプロイ)

基本的に Web.config の変更と同様の動きの様子(デプロイも結局の所は、ファイルのコピーなので)。

試してはいないが、DevOps からのデプロイ時なども同じ状態になるのではないかと思われる

Azure ポータルでのアプリ設定の変更

基本的には、Azure ポータルでの「再起動」と同じフローに見える。

ただこちらの操作の場合、既存リクエスト処理の終了待ち状態で受けた新たなリクエストは、終了待ちのワーカープロセスではなく新たなワーカープロセス上で処理されるようで、ここが「再起動」時と異なる。

また、終了待ちのワーカープロセスが終了するまで新しいワーカープロセスも起動しないようなので、新たなリクエストは終了待ちのワーカープロセスが終了するまで、待機することになる様子。

以下の説明を見る限り、一時的に重複してワーカープロセスが起動しそうな感じだが、自分が確認した限りでは、これは常時接続オンの場合の挙動だった。

常時接続オンの場合 常時接続オンの場合は、稼働中ワーカープロセスのシャットダウンを待たずに新規ワーカープロセスを並行起動して新しいリクエストを処理するため、稼働中ワーカープロセスのシャットダウン待ちの状態は発生しない。

詳細な動作はアンドキュメンテッドだが、アプリ設定変更後のリクエストも、新規ワーカープロセスがリクエスト待ち受け可能な状態になるまでは旧ワーカープロセスで受け付けてレスポンスを返し、新規ワーカープロセスがリクエスト待ち受け可能になったタイミングで新しいリクエストは全て新規ワーカープロセスで処理し、入れ替わりに旧ワーカープロセスがシャットダウンされるように見受けられる。

スロットのスワップ

まず、スワップ元スロットにターゲットスロットのアプリ設定などをコピーして、準備が行われる。

この準備が完了するまでは、スワップ先のスロットで通常通りリクエストが処理される。 スワップ元スロットでの準備が完了したら、FQDN の付け替えを行ってスワップを完了する。

この時点からのリクエストは、スワップ元で準備していたワーカープロセスで受けることになるが、既に準備は完了している状態なので、ブラウザの待ち時間などは基本的に発生しない (はず。あっても数秒程度)。 スワップ完了までは、大体数分ほどかかる。

余談だが、スワップ元スロットのアプリ設定等は、スワップ完了してターゲットでのリクエスト処理が開始された後に、行われる。

スワップの詳しい内部動作は MS の資料がどこかにあったはずだが、捜索中・・・

プランの変更

Azure ポータルでの「再起動」と同様、既存のワーカープロセスが落とされて、開始可能状態となるように見える。

html のキャッシュ抑制方法

まず一番基本の、html ファイルのヘッダーにメタ情報として指定する方法は、下記。Cache-Control については no-cache もあるけど、no-store の方がキャッシュされない感じ。

<head>
  <meta http-equiv="Pragma" content="no-cache">
  <meta http-equiv="Cache-Control" content="no-store">
  <meta http-equiv="Expires" content="0">
</head>

ただ、html のキャッシュ抑制対応するには html ヘッダーの meta タグだけでは不十分なようで、キャッシュが表示される場合がある。 その場合 http レスポンスヘッダーにも追加することで、回避出来るみたい (静的 html ファイルも含めて)。

ASP.NET の場合、Web.config に以下のように設定を追加する。

Web.config

<system.webServer>
  <httpProtocol>
    <customHeaders>
        <add name="Pragma" value="no-cache"/>
        <add name="Cache-Control" value="no-store"/>
        <add name="Expires" value="0"/>
    </customHeaders>
  </httpProtocol>
</system.webServer>

ASP.NET MVC アプリの脆弱性対策について

対象

ASP.NET MVC 5 (.NET Framework) + Azure Web Apps を対象とする。

不要なレスポンスヘッダーの削除

既定のままだと、レスポンスヘッダーには以下のような ASP.NET を示唆する情報が出力される。

  • Server: Microsoft-IIS/10.0
  • X-AspNet-Version: 4.0.30319
  • X-AspNetMvc-Version: 5.2
  • X-Powered-By: ASP.NET

それぞれ、以下のように対応する。

  • X-AspNet-Version
  • X-Powered-By
  • Server

Web.config

<system.web>
  <!-- enableVersionHeader 属性を追加 -->
  <httpRuntime enableVersionHeader="false" targetFramework="4.6.1"/>
</system.web>

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By"/>
    </customHeaders>
  </httpProtocol>

  <security>
    <requestFiltering removeServerHeader="true"/>
  </security>
</system.webServer>
  • X-AspNetMvc-Version
  • Server

Global.asax.cs

protected void Application_Start()
{
    MvcHandler.DisableMvcResponseHeader = true;
}

protected void Application_PreSendRequestHeaders()
{
    HttpContext.Current.Response.Headers.Remove("Server");
}

Server については、web.config と Global.asax.cs のどちらでも削除可能。 web.config の場合は VS がなぜか警告してくるが、VS の問題のようで実際の動作は問題ないので、気にならなければ web.config で良いかと思われる。

なお、Server の削除については、上記対応方法だと正確には正常レスポンス時しか削除されない (web.config と Global.asax.cs どちらも)。 例えば、FireFox などでリクエストヘッダーの Host の値を改変して再送するとエラーとなるが、その場合は Server が出力されてしまう。

IHttpModule を継承したモジュールを使用したり、Web.config で runAllManagedModulesForAllRequests 属性を使用するなどの方法はあるが、完全に削除できるようには見えないため、完全削除は諦めた方が無難と思われる。

特に後者の runAllManagedModulesForAllRequests 属性を使用する方法は、パイプラインの動きを変えて静的なファイルについてもパイプラインを通るようになってしまうため、使用はお勧めできない。

セキュリティに関するレスポンスヘッダーの追加

既定のままだと、セキュリティに関する以下のレスポンスヘッダーが出力されない。

  • X-Content-Type-Options
  • X-Frame-Options
  • X-XSS-Protection
  • Strict-Transport-Security
  • Content-Security-Policy
  • X-Download-Options

それぞれ、以下のように対応する。

Web.config

<system.webServer>
  <httpProtocol>
    <customHeaders>
        <add name="X-Content-Type-Options" value="nosniff"/>
        <add name="X-Frame-Options" value="SAMEORIGIN"/>
        <add name="X-XSS-Protection" value="1"/>
        <add name="Strict-Transport-Security" value="259200"/>

        <!-- CSP ヘッダーは、何を適用する必要があるのか把握した上で適切な設定を行う必要がある。インラインスクリプトの許可なども含まれるので、プロジェクト全体の実装方針に影響する -->
        <add name="Content-Security-Policy" value="default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; "/>

        <add name="X-Download-Options" value="noopen"/>
    </customHeaders>
  </httpProtocol>
</system.webServer>

追加ヘッダーの値についてはサイト毎に要求される内容も異なるため、どの設定値が適切かは検討する必要がある。上記はただの一例。

特に CSP ヘッダーは、何を適用する必要があるのか把握した上で適切な設定を行う必要がある。 インラインスクリプトの許可なども含まれるので、プロジェクト全体の実装方針に影響する。

上記は、CSS はインライン許可、スクリプトもインライン及び eval() 許可する場合の設定。 iframe で他サイトを読み込む場合は frame-src が必要だし、他にも色々種別がある。

なお、類似するヘッダーとして X-WebKit-CSP および X-Content-Security-Policy ヘッダーが存在するが、共に 2012 年前後の古いブラウザで使用されていたヘッダーなので、現在は不要。

CSRF について

CSRF は、MVC の AntiForgeryToken で対応する。メソッドは HttpPost が対象。Get はそもそも登録系の処理には使用しないので・・・。

Session Fixation 問題について

ASP.NET のセッション情報を使用する限り、Session Fixation 問題への完全な対応は、難しい様子。 認証処理はセッションを使用するのではなく、Session Fixation 問題が発生しないフォーム認証を使って対応する。

クッキーのセキュア化

クッキーのセキュア化は、主に 2 つ。HttpOnly および Secure 属性の付与となる。

HttpOnly 属性は以下の設定を行う。

Web.config

<system.web>
  <httpCookies httpOnlyCookies="true"/>
</system.web>

Secure 属性の付与は、Global.asax.cs の Application_EndRequest とかで動的に設定した方が良いと思われる (特に問題なければ全クッキー一律に)。

localhost での実行時は、基本的に http での実行になるはずなので、一律に Secure 属性を適用すると、ローカルで実行できなくなる。 その為、ローカル以外での実行時に動的に適用した方が良いかと思われる。

なお、Secure 属性が適用されているかブラウザの F12 開発者ツールで確認する場合は、リクエストクッキーではなく、レスポンスクッキーを見る必要があるので、注意。

電動ノコギリのすすめ

普通のノコギリで庭の木の枝を切るのに疲れてしまって、電動ノコギリを買ったら非常に便利だったので、その紹介。

高儀 EARTH MAN 14.4V充電式電気のこぎり

電動ノコギリはいくつもあるが、自分はこの電ノコが使うの初めてで他のは使ったことないので、それ前提で参考にしてもらえれば。

f:id:poke_dev:20190302162718j:plain

普通のノコギリで大変なこと

  • 切るのに時間がかかる
  • 体力が削られる
  • なかなか切れないので精神力も削られる

電動ノコの場合

  • 切るのに時間がかからない。チェーンソーのようにズバズバ切れるわけではないけど、大体 1 分で 1cm ぐらい切れる(個人差はあると思います)
  • 体力が削られない。ただ、全く体力が要らないわけではなく、動作時の振動が凄いのでそれに耐える必要はある。けど、ノコギリを自分で引くのに比べたら楽
  • 振動さえ耐えていれば後は電ノコおまかせで切れるので、精神面でも健全
  • 上位タイプとしてチェーンソーとかあるが、あっちはガソリン使ったりもするので、それに比べたら動力が電気の電ノコはお手軽
  • ノコギリと比べるとズバズバ切れるので、切る作業が楽しくなる(個人的な感想です)

電源ケーブルタイプか、バッテリータイプか

たぶん、電ノコを初めて買う場合、迷う点の一つに電源ケーブルタイプを買うか、バッテリータイプを買うかがあると思う。 自分の場合はバッテリータイプを買ったが、今の所、満足しかない。

バッテリーは、大体 2, 30 分使えて、充電には 3, 40 分ぐらいかかる感じ。 ちょっとした作業だったら 2, 30 分使えれば大抵問題ないと思うが、自分が買った電ノコはバッテリーが取り外し出来るタイプなので、必要に応じて、もう一つバッテリーパックを購入するというのも可能(本体の熱が大丈夫なのかは不明)。

バッテリータイプの電ノコでも、取り外しが出来ないタイプがあるらしく、その場合はそういう予備バッテリー方式が使えないと思うので、注意が必要と思う。

電源ケーブルタイプと比べてパワーが弱いのかなと買う前は思っていたが、自分としては特に問題なかった。ただ、電源ケーブルタイプを使ったことがないので、実際どれ位の差異があるかは不明。

使い方とか

基本的には電動の振動に耐えるだけで後は勝手に切れる感じだが、手動でも軽くノコギリ的な動きをさせた方が、切れやすい感じがある。 如何に同じ方向に刃を当て続けるかがキモ。

他、電ノコの特記事項とか

  • 比較するのもどうかとは思うが、ガソリン使うチェーンソーと比べると、流石に非力だと思う。10cm ぐらいまでの枝とかであれば問題ないと思うが、それ以上だと用途として外れると思う
  • 仕組み上、切る対象が固定されていないと、切れない。なぜかと言うと、電ノコの動きに合わせて対象も動いてしまうから。なので、長く飛び出てる枝とかは切れないと言うか、そういうのは用途違うので、普通に枝切りバサミ使う必要がある
  • 上述したように、振動が結構凄い。なので、電動だから非力な高齢者でも楽に切れるかと言うと、そううまくはいかないと思う。少なくとも普通のノコギリで作業ができないような人だと、電ノコも厳しいと思われる

自分が買った電ノコの特記事項とか

安全装置として、親指の辺りに配置されているボタンを押しながらじゃないと、トリガーを引いても作動しない。この作りが、右手で持ってトリガーを引く前提になっているっぽいので、左利きだと使うの厳しそう。

アマゾンとかのレビューでは、そもそも右利きでもこの安全装置のボタンを押しながらだと長時間作業はキツイというコメントを見かけるが、安全やコストとのトレードオフな面もあるので、個人的には仕方ないかなぁと思った。(長時間押し続けるのがキツイと言う感想自体は同意)

結論

ノコギリを使う場面が定期的にあるのであれば、絶対電ノコ持っていた方が良い。価格も安いやつであれば、1 万 5 千円もしない。

現場からは、以上です。

タニタのデジタル温湿度計買ったけど、壁掛けはどうするのってなった時

柱に温湿度計かけようと思ってこんなのを買って、

壁掛けするための穴もこんな感じに開いてるのに、

f:id:poke_dev:20190227233704p:plain

肝心の穴にかけるネジが付属してないやんけって話。 木の柱であれば、以下のネジでうまく壁掛けできました。

八幡ねじ 壁掛用ねじ 3.5×20mm

八幡ねじ 壁掛用ねじ 3.5×20mm

実際に木の柱にネジを入れる時は、キリやら電動ドライバやらがないと辛いけど、それはまた別の話。

現場からは以上です!

自分用確定申告メモ

来年の自分へ・・・

自分の属性

  • 派遣として働いてる
  • 社会保険は基本的に厚生年金+健保だが、たまに無職の期間あるので、その場合は国民年金+任意継続保険に切り替わる
  • 株メインで投資やってる
  • ふるさと納税も使う
  • 年末調整は使わない

基本

  • 確定申告は全て Web サイトで行う。入力したデータの一部は来年以降も引き続き使えるので、非常に便利
  • 作成する申告書の種類は、所得税
  • e-tax も便利だけど証明書の更新が必要なこともあり、最近は Web からダウンロードした PDF をコンビニのプリンタでプリントアウトして、郵送
  • e-tax は基本的に添付書類不要(手元に保管しておく必要があるらしい)なので、状況によって利用を検討

確定申告時に必要となる書類とか

  • 給与所得の源泉徴収票。最近は Web からのダウンロードになったので、この場合手元でとっておく必要がある書類はない
  • 生命保険、医療保険個人年金保険などの控除証明書。基本的に年末近くにハガキで届くので、捨てることはないと思う
  • 国民年金の納付領収書
  • 国民健康保険や任意継続保険の納付領収書。派遣健保の任意継続保険は再発行の依頼が可能
  • 証券会社から送られる特定口座年間取引報告書。基本的に年明けてから郵送されるので、捨てることはないと思う
  • ふるさと納税の寄付金受領証明書

株式関係

  • (株式売却側で損失がある場合) 配当金の課税方法は、申告分離を選択。総合だと株式側との合算ができないので、株式側の損失で埋め合わせることができなくなる
  • 繰越損失は、来年以降使用する残がある限り、毎年提出が必要になるので注意。もし提出し忘れた場合、まだ繰り越せる損失が残っていたとしても、その時点で全てリセットされる

社会保険料関係

  • 医療費の総額、自分が窓口で支払った金額、及び支給された高額療養費については、基本的には健保から送られてくる医療費のお知らせに全て記載されているので、そちらを使用できる。ただ、期間が 1 月から 10 月の診療までと全期間ではないので、注意
  • 高額療養費と同様、個人的に入っている医療保険から支給された給付金も補填金として差し引く必要がある。そのため、医療保険の給付に関する書類もとっておく
  • 高額療養費と医療保険からの給付金を考慮すると、10 万円を超えるのは基本的にほとんど発生しないように思える

ふるさと納税関係

郵送料

郵送は定形外郵便物の規格内。 ふるさと納税で 6 枚ぐらい受領証あると、定形内最大の封筒に入れて 90g ぐらいなので、ギリギリ 100g までの 140 円。

ただ、封筒が相当パンパンになるので、無理しないで A4 の封筒(角 2)に入れた方が無難。その場合重量は 110g ぐらいになるので、切手は 150g までの 205 円となる。