EatSmartシステム部ブログ

ウェブサイトの開発や運営に関する情報です。

VPN切替に伴う本番サーバー接続方法の変更について

5月上旬にインフラチームにてVPNの切替を行いましたが、切替前はVPN経由で本番サーバーへ接続出来ていましたが、切替後に接続出来なくなってしまいました。
今回はその経緯及び切替後の接続方法変更についてまとめてみました。

切替前後の構成

切替前はSSL-VPN経由で、本番サーバーに接続していました。

f:id:eatsmart:20200629234539j:plain

切替後はOpenVPN経由になりましたが、社内サーバーへの接続は可能でしたが、本番サーバーに接続出来なくなりました。
そこで、原因を調査した結果切替前とは別のローカルセグメントで接続している為、本番サーバーのF/Wで接続不可の状態となっていました。

f:id:eatsmart:20200630000242j:plain

本番サーバーへの接続要件

現状の本番サーバーへの接続要件として、下記条件を満たす必要がありました。

  • 一部のシステム担当以外のPCからは本番サーバーへの接続を不可とする

  • 一部のシステム担当PCからSSHによる本番サーバーへの接続を可能とする

  • 一部のシステム担当PCからDBクライアントによる本番DBサーバーへの接続を可能とする

接続方法の変更

切替後の環境で、上記要件を満たす為に実現案の検討を行いました。
当初は本番サーバーに新たなローカルセグメントのF/Wを追加する案も上がりましたが、現状のセキュリティ強度を下げずに接続可能とする方法を検討した結果、変更後は踏み台サーバーを経由して本番サーバーに接続する事にしました。

f:id:eatsmart:20200630000528j:plain

DBサーバーへの接続について

各PCからのSSH接続は踏み台サーバー経由で本番サーバに接続可能となりましたが、DBサーバーへ接続するにはポートフォワードする必要があり検討した結果、各PCのSSHクライアント(Putty)でトンネリング設定を行いDBクライアント(PSqlEdit)から接続する事にしました。以下にPuttyのトンネリング設定及びPSqlEditの接続先設定について記載します。

Puttyセッション設定画面 f:id:eatsmart:20200629235108j:plain

Puttyトンネリング設定画面 f:id:eatsmart:20200629235223j:plain

PSqlEditの接続先設定画面 f:id:eatsmart:20200630171307j:plain

結果、SSH及びDBサーバーに無事接続することが出来ました。

データベースのバックアップ手順の見直し

今回は、前日実施したデータベースのバックアップに関することを書きたいと思います。

ディスク使用量の警告

イートスマートでは管理しているすべてのサーバをZabbixで監視しています。 ある日、イートスマートのデータベースとして利用しているサーバの、ディスク使用量に関する警告が届きました。

www.eatsmart.jp

以下のような内容です。

Problem started at 05:23:59 on 2020.05.28
Problem name: Free disk space is less than 10% on volume /
Host: database

この時間帯は、PostgreSQLのCOPYコマンドを利用して日毎バックアップを実施しています。 このバックアップはスナップショットとして活用しており、必要に応じて過去のデータを参照したり、そこから書き戻すために利用しています。

日毎バックアップの手順

この日毎バックアップは、以下の手順で実施しています。

  1. COPYコマンドでバックアップ対象のテーブルからファイルを作成
  2. tarコマンドで1で作成したファイルをtar.gzへ固めアーカイブを作成
  3. 1で作成したファイルを削除

この手順の問題点として、1と2の間で一時的にファイルとアーカイブが存在するため、ディスクの使用量が多くなることが挙げられます。 このため、Zabbixからディスクの使用量の警告が届くようになりました。

対処方法

対処方法としていくつか検討しましたが、今回は手順を見直すことでディスクの使用量を減らすことにしました。 バックアップの手順を以下のように変更しました。

  1. COPYコマンドでバックアップ対象のテーブルのうち1つのテーブルからファイルを作成
  2. 1で作成したファイルをgzipへ圧縮
  3. すべてのバックアップ対象のテーブルの処理が終わったら4へ、終わっていなければ1へ戻る
  4. tarコマンドで2で作成したファイルをtarへ固めアーカイブを作成
  5. 1で作成したファイルを削除

ディスクの使用量を減らすため、ファイルを都度gzipで圧縮しています。 こうすることで、ディスクの使用量を1/4程度に減らすことが出来ました。 注意することとして、アーカイブの形式がtar.gzからtarに変わったことで、テーブルの内容を参照する手順が変わったことがあります。

まとめ

これでZabbiから警告が届かなくなりました。 今回はバックアップの手順の見直しで対処しましたが、バックアップに関して議論をするきっかけになりました。

  • そもそもいまのバックアップ内容で問題ないのか?(スキーマのバックアップが必要ではないか?)
  • COPYコマンドではなく、pg_backupのほうが良いのではないか?
  • バックアップを実施するサーバとしてマスタが適切か?(スレーブで良いのではないか?)

などです。 以前から仕組み化されており、問題がある訳ではなく内容に疑問を持つこともありませんでした。 今回の作業を通して、システム部メンバーの考え方を聞く良いきっかけになりました。

Postfixにたまった不要なメッセージの削除

MTAのPostfixに不正なサーバーから大量にメールを送られ、それに対して自動で返信しようとしてできなかった場合に、MAILER-DAEMONが再送しようとして輻輳することがありました。

それらを一度に削除することを試みました。

各コマンド

1. キューにたまったメッセージの一覧

postqueue -p

2. MAILER-DAEMONの抽出

grep 'MAILER-DAEMON'

3. 先頭の文字列(MessgeID)の抽出

awk '{print $1}'

4. activeキューのマーク削除

postqueue -p では、activeキューにあるメッセージのIDに*が付くようです。

* The message is in the active queue, i.e. the message is selected for delivery.

sed s/*// 

5. ID指定でメッセージ削除

postsuper -d

まとめると

全体をパイプでつないで、最後のpostsuperはxargsで引数を渡すと

postqueue -p | grep 'MAILER-DAEMON' | awk '{print $1}' | sed s/*// | xargs -L 1 postsuper -d

と、なります。

Spamhausにブラックリスト登録された場合の対処について

今回は、自社のSMTPサーバーがブラックリスト登録された場合の対処方法についてまとめてみました。

ブラックリストとは

ブラックリストとは、DNSBL(Domain Name System Black List)と呼ばれ、こちらに登録されると各メールサービス(outlook等)から受信拒否扱いされます。
また、DNSBLを取り扱うブラックリスト団体として「Spamhaus」が最も有名で、今回はSpamhausを例に挙げて解説していきます。

www.spamhaus.org

Spamhausでのブラックリスト登録確認について

Spamhausでブラックリストされたかを確認するには、下記ページよりIPアドレス or ドメイン名を入力することで確認が行えます。

www.spamhaus.org

Spamhausでのブラックリスト登録の解除について

ブラックリスト登録されてた場合、上記確認フォームで「Listed」と表示されますので以下の手順で解除申請が行えます。

  1. 表示されているドメインをクリック

  2. SBL/XBL/PBLのいずれかの Removal formが表示されますのでクリック

  3. 表示された解除フォームにて「メールアドレス」と確認のための「表示されている番号」を入力して「Remove」をクリック

※通常30分程度で解除されます

ブラックリスト登録されない為の対策について

そもそもブラックリスト登録されない為の対策についてまとめてみました。

原因1 無効なメールアドレスに何度も送信を繰り返す

長期に渡りサービス運営していると、どうしもて非アクティブなユーザーが発生し、そのユーザーが所有していたメールアドレスが無効なアドレスとなることがあります。
その無効なアドレスに対して、何度も送信を繰り返すとブラックリスト登録される原因となります。

対策

メールアドレスのクレンジングを定期的に実施する
sendmail/postfix等自社でメールサーバーを運営してる場合、SMTPサーバーのログからエラーリストを作成し

  • システムで自動送信等を行わない
  • メルマガ等一斉送信の対象者から除外する

等の対策が必要です。

原因2 スパムトラップにメール送信する

スパムトラップとは、ブラックリスト団体等があらかじめ用意したスパムトラップ用メールに送信すると、ブラックリスト登録される仕組みです。
また、スパムトラップ用メールは、過去に使用されていたメールアドレスから長い間(1年かそれ以上)使われていないものが、再利用されています。

対策

原因1の対策同様に無効なメールアドレスのクレンジングを行う必要があります。

原因3 大量のメールを特定IPアドレスから短期間で一斉送信する

会員向けのメルマガ配信等で、自社SMTPサーバーの特定IPアドレスから大量にメール配信するとがあるかと思いますが、その場合ブラックリスト登録される可能性がある為、以下の対策が必要です。

対策

  • 一斉メールを送信する際は、1通毎の送信間隔をあける
  • 複数のSMTPサーバー(別のIPアドレス)から分散して送信する


上記以外にもさまざまな原因が考えられますが、メールサーバーを運用されている方は、いずれにしてもメールアドレスのクレンジングは重要と思われますので定期的に実施することをオススメします。

テンプレートパーツで構成されるサイトのGoogleAdManager実装について

弊社のサイトは、ページ内の共通パーツをテンプレートとして作成し、ページごとに組み合わせて構成している実装が多いです。 また、ディスプレイ広告の配信には、GoogleAdManager(旧DFP)を使用していることが多いのですが、この組み合わせだと生じやすい問題があったので、それを紹介します。

GoogleAdManager

GoogleAdManager(以後、GAM)は、Google社が提供している以下の広告配信ツールです。

Google アド マネージャー - 統合型の広告管理プラットフォーム

GAMを使うと、Googleアドセンスやその他のSSPの広告枠、サイト内誘導用の自社バナーの掲載について、GAMへの入稿と設定で一元管理できるので、とても便利です。

基本的な考え方としては、ページ上の広告表示スペースをGAMで「広告ユニット」として定義し、そこで発行されるタグをHTML上に実装します。その後、出稿したい内容を「広告申込情報」として設定することで、対象とした広告ユニットに配信することができる様になります。

GAMの管理画面上では、自社バナー掲載の場合は、表示回数やクリック数の測定が可能です。また、アドセンスの場合は、表示回数やCPM、売上を測定可能で、その他のSSPも表示回数と設定CPM(仮想CPM)からの売上の集計が可能です。

広告サーバーとしての大きな特徴としては、ダイナミック アロケーションと言って、広告申込情報に対して設定した仮想CPMより高い金額のアドセンス広告があった場合は、アドセンスが優先して表示し収益の最適化を行うことができます。

GAMの実装の特徴

GAMのタグは、以下の様にHTMLのheadとbodyの2ヶ所に実装することにより、bodyの実装した場所に広告を表示することができます。

  • head
<script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<script>
  window.googletag = window.googletag || {cmd: []};
  googletag.cmd.push(function() {
    googletag.defineSlot('/xxxx/xxxxxxxx', [300, 250], 'div-gpt-ad-0').addService(googletag.pubads());
    googletag.pubads().enableSingleRequest();
    googletag.enableServices();
  });
</script>
  • body
<!-- /xxxx/xxxxxxxx -->
<div id='div-gpt-ad-0' style='width: 300px; height: 250px;'>
  <script>
    googletag.cmd.push(function() { googletag.display('div-gpt-ad-0'); });
  </script>
</div>

ページ内に複数の広告枠を実装する場合は、headは以下の様にdefineSlotを続けて呼ぶ形にします。

  • head(複数枠)
<script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>
<script>
  window.googletag = window.googletag || {cmd: []};
  googletag.cmd.push(function() {
    googletag.defineSlot('/xxxx/xxxxxxxx', [300, 250], 'div-gpt-ad-0').addService(googletag.pubads());
    googletag.defineSlot('/xxxx/yyyyyyyy', [300, 250], 'div-gpt-ad-1').addService(googletag.pubads());
    googletag.defineSlot('/xxxx/zzzzzzzz', [300, 250], 'div-gpt-ad-2').addService(googletag.pubads());
    googletag.pubads().enableSingleRequest();
    googletag.enableServices();
  });
</script>

HTMLをテンプレート分割した場合の問題点

はじめに書いたように、弊社のサイトは、ページ内の共通パーツをテンプレートとして作成し、ページごとに組み合わせて構成している実装が多いです。 具体的には、

  1. サイトのヘッダやパンくず、フッタ等の全ページ共通で使用するテンプレート
  2. 一覧系ページの下部に入れる共通パーツ、詳細系ページの下部に入れる共通パーツ、など、ページのタイプ毎に分けて使用するテンプレート
  3. ページのメイン部分のコンテンツ(これは共通パーツではないので、テンプレート化はされない)

など、いくつかの種類に分けられます。

で、それぞれのテンプレートの中に広告枠を実装していくと、1に実装した広告枠は全ページで表示され、2に実装した広告枠は該当共通パーツを使用するページで表示され、3に実装した広告枠はそれぞれのページで表示されることになります。

この時、テンプレートの組み合わせでページを作る利点としては、ページで使いたいものを使いたい場所にインクルードすれば良いことなのですが、GAMの広告枠を表示するためには上記したように、HTMLのheadで使用する広告枠についてdefineSlotしないとなりません。 つまり、ページ本体は共通パーツをインクルードするだけで実装できるものの、パーツの中にどんな広告枠が使用されているかを把握し、各ページでdefineSlotが必要となるので、共通パーツの可用性や変更自由度がかなり制限されることになります。

広告枠の評価

それでは、HTMLのheadに、サイトで使っている広告枠全てのdefineSlotしたコードをテンプレート化してインクルードすれば良いのでは?と考えたのですが、それも大きな問題があります。

GAMのサーバー(Google)側で、defineSlotされたのに実際にdisplayが呼ばれない広告枠について、広告表示リクエストがありながら広告が配信されない(fill rateが低い)広告枠と判断され、広告枠としての評価が下がります。すると、良い広告が配信されなくなり、収益性が下がることが予想されます。また、場合によっては、空リクエストの多い不審な広告枠と判断されることもあるのではないかと思っています。

弊社では、上記の広告枠実装ページの複雑さと枠定義の呼び出し(defineSlot)について、独自の実装で対応しているのですが、その方法については次回紹介したいと思います!

Docker Registryのクリーンアップ

イートスマートでは、Dockerイメージを管理するため、ローカルネットワークにDocker Registoryを運用しています。 2018年にすべてのアプリケーションをDockerに移行してから約2年が経過し、ストレージの使用量が増加してきました。 今回は、Docker Registryのクリーンアップを行い、ストレージの使用量を減らしてみます。

GCを実行する

docs.docker.com

公式の手順を試してみます。 まずコンテナの起動時に環境変数を指定します。 この設定を行わないと、GCを実行してもファイルが削除されません。

docker run -d \
  --name docker-registry \
  --env="REGISTRY_STORAGE_DELETE_ENABLED=true" \
  registry

次に、config.ymlという設定ファイルを作成します。

version: 0.1
storage:
filesystem:
    rootdirectory: /var/lib/registry

コンテナに入りGCを実行すると、ログが出力されました。

# bin/registry garbage-collect config.yml
~省略~
INFO[0285] Deleting blob: /docker/registry/v2/blobs/sha256/04/049cadc74ece94005779f2024778d22dbb5d1180687769064a4675a0ac187fb9  go.version=go1.7.6 instance.id=e19746de-8a11-4859-8153-b2fa478200d9
blob eligible for deletion: sha256:053d5ff01a9ecdac9fbaf666e0e609dfb1c1b8ec1c06c7f30d2b632b5cafec5a
INFO[0285] Deleting blob: /docker/registry/v2/blobs/sha256/05/053d5ff01a9ecdac9fbaf666e0e609dfb1c1b8ec1c06c7f30d2b632b5cafec5a  go.version=go1.7.6 instance.id=e19746de-8a11-4859-8153-b2fa478200d9
blob eligible for deletion: sha256:445837ba62b8da8508fadcfddb51b0e8391ddbfce89bcb860bae02b2ffe43576
INFO[0286] Deleting blob: /docker/registry/v2/blobs/sha256/44/445837ba62b8da8508fadcfddb51b0e8391ddbfce89bcb860bae02b2ffe43576  go.version=go1.7.6 instance.id=e19746de-8a11-4859-8153-b2fa478200d9
blob eligible for deletion: sha256:815b9554bd27a47bef3a23d81341925830d4fd69b9e79c117592f3ed0ff9aa24
INFO[0286] Deleting blob: /docker/registry/v2/blobs/sha256/81/815b9554bd27a47bef3a23d81341925830d4fd69b9e79c117592f3ed0ff9aa24  go.version=go1.7.6 instance.id=e19746de-8a11-4859-8153-b2fa478200d9

いくつか削除されましたが、dfでストレージの使用量を調べてみても以前とそれほど差がありません。 ファイルを確認しても、それほどファイルが削除されていないようです。 原因を調べてみると、同一のタグを使いまわしているとリポジトリ配下のtagが別れないのでGCで削除が出来ないようです。 イートスマートではイメージをpushする際にタグにバージョンをせずlatestを利用しているのですが、この運用はまさに該当してしまいました。

リポジトリを削除する

つぎに、リポジトリの削除を試してみました。 リポジトリの削除はAPIを利用することも出来ますが、ディレクトリを削除することでリポジトリを削除しました。

# rm/var/share/docker-registry-dev/docker/registry/v2/repositories/eatsmart-docker-image/

削除すると、docker pullで取得出来なくなります。

# docker pull registry:5000/eatsmart-docker-image
Using default tag: latest
Error response from daemon: manifest for registry:5000/eatsmart-docker-image:latest not found

GCを実行すると、前回に比べて大量のログが出力されました。

# bin/registry garbage-collect config.yml
~省略~
INFO[0475] Deleting blob: /docker/registry/v2/blobs/sha256/fc/fc709bdf02c32b035a55ca326f4c2e2690729a61ea66e3b7405e2a36737d7069  go.version=go1.7.6 instance.id=98eae377-7a7d-42b3-bf81-a43749e8b7b8
blob eligible for deletion: sha256:7ac6dd671c054f72bb2c688b15740830d3058ba29343259a88723dc07159f271
INFO[0475] Deleting blob: /docker/registry/v2/blobs/sha256/7a/7ac6dd671c054f72bb2c688b15740830d3058ba29343259a88723dc07159f271  go.version=go1.7.6 instance.id=98eae377-7a7d-42b3-bf81-a43749e8b7b8
blob eligible for deletion: sha256:b028e0e97347fcc71cc92842b7749b8cfe7141b16af4d439e24b202fc048bc86
INFO[0475] Deleting blob: /docker/registry/v2/blobs/sha256/b0/b028e0e97347fcc71cc92842b7749b8cfe7141b16af4d439e24b202fc048bc86  go.version=go1.7.6 instance.id=98eae377-7a7d-42b3-bf81-a43749e8b7b8
blob eligible for deletion: sha256:d8ce74dd159ad8800028e1356c73e8daa7d78047a93ba602f56e199cf80b1502
INFO[0475] Deleting blob: /docker/registry/v2/blobs/sha256/d8/d8ce74dd159ad8800028e1356c73e8daa7d78047a93ba602f56e199cf80b1502  go.version=go1.7.6 instance.id=98eae377-7a7d-42b3-bf81-a43749e8b7b8
blob eligible for deletion: sha256:ed82a71e3c941bba568e960556727a7806eabf702a7d450a1004a54910fc9fcd
INFO[0475] Deleting blob: /docker/registry/v2/blobs/sha256/ed/ed82a71e3c941bba568e960556727a7806eabf702a7d450a1004a54910fc9fcd  go.version=go1.7.6 instance.id=98eae377-7a7d-42b3-bf81-a43749e8b7b8

dfでストレージの使用量を調べてみると、数GB減少していました。 この後、イメージをpushすると問題なくdocker-pullすることが出来、起動することも確認できました。

まとめ

以上の手順で、約200GBの使用量を削減することが出来ました。 今回GCを実行したことで、イメージのタグの管理に課題があることがわかりました。 引き続き、タグの管理を見直したいと思います。

Web会議を利用してみて

コロナ対策でテレワークを実施している方が多いのではないかと思います。
私も2月下旬からWFHの通達があり自宅で作業をする様になってから1ヵ月半程経ちますが、元々ノートPCやVPN等の環境が整備されていたため、勤務形態の影響を受けずにテレワークに移行出来ました。
そんな中でも一番大きく変わったのが、全てのコミュニケーションをWeb会議で行う様になった事だと思います。
幸いにも、Web会議の環境もコロナ対策前から準備されていた為、導入はスムーズに行えましたが、テレワークを開始してからいくつかのWeb会議を利用してみて感じた事などを共有できたらと思います。

各Web会議の特徴

私の場合は、Workplaceビデオチャット/Google Hangouts Meet/ZoomでWeb会議を利用してみましたがそれぞれの特徴や感じた事などをまとめてみました。

Workplaceビデオチャット

特徴

Facebookが提供するエンタープライズ向けSNSシステムWorkplace from Facebook(有料)に搭載されているチャット機能になり、テキスト・音声通話・ビデオチャットが行えます。
会議の主催者・参加者伴にWorkplaceのアカウントが必要です。
音声通話やビデオチャットを個人またはグループ(最大50人)で行え、操作も非常に簡単でブラウザorスマホアプリで利用可能です。
もともと会社としてWorkplaceを導入してた経緯もあり、一番利用頻度が高いです。

ja-jp.workplace.com

利用方法

Workplaceチャットの利用方法については下記を参照願います。 businesschatmaster.com

気になった点

気になった点としては、PCの画面共有を行う場合別途Chrome拡張機能をダウンロードする必要があります。

PCの画面共有用Chrome拡張機能 chrome.google.com

後、音声通話やビデオチャットを利用していて、(ネットワークの負荷状況によりますが)若干不安定な気がしました。

Google Meet

特徴

Googleが提供しているビジネス向けビデオ会議ツールで、最大250人でビデオ会議が行えます。
GSuite(有料)というグループウェアサービスに統合されており、ブラウザorスマホアプリから会議に参加できます。
会議の主催者はGoogleアカウントが必要ですが、参加者はアカウント不要で主催者から招待を受ければ参加できます。

便利な機能としては、PC画面の共有を標準で行えます。
また、Googleカレンダーの予定からダイレクトにビデオ会議を開始できます。

gsuite.google.co.jp

以前は、ビデオハングアウトという名称でサービスを行っておりましたが、現在はMeetに変更されております。
また、Meetとハングアウトの比較は以下の通りです。

support.google.com

利用方法

Google Meetの利用方法については下記を参照願います。

cloud-work.jp

気になった点

特に気になった点等はありませが、Zoomに比べるとやや機能が劣るかなと思いました。

Zoom

特徴

Zoom社が提供している、Web会議システムでエンタープライズ版(有料)で最大500人迄参加できます。
無料版も用意されていて最大100人のグループ会議が40分まで利用可能です。
会議の主催者はZoomアカウントが必要ですが、参加者はアカウント不要で、管理者から送られてきたリンクをクリックするだけでミーティングに参加できます。
便利な機能としては、PC画面共有/ホワイトボード/ブレイクアウトルーム(参加者を複数のグループに分ける)等豊富に揃っています。

音声や画像も鮮明でほぼ遅延なく安定していました。

zoom.us

利用方法

Zoomの利用方法については下記を参照願います。

hashikake.jp

気になった点

気になる点としては、セキュリテー上の問題として下記2点が挙げられています。

  • ソフトウェアのセキュリティ脆弱性

  • Zoom bombing(第三者がミーティングに参加して音声や画像等で妨害する事象)

また、上記について現状(2022/4/10時点)の対応状況を調査してみたところ

  • ソフトウェアの脆弱性については、Zoom側で随時対応が進んでいる様です。 Zoomを利用する際は最新のソフトウェアにアップデートする必要があります。

  • Zoom bombingについてですが、Zoomの場合9桁の数字が一致すれば第三者がミーティングに参加できてしまう為、対策としては

 ミーティングにはパスワードを設定する。
 ミーティングIDはなるべく毎回変更する
 ミーティングID/パスワードを関係者以外に公開しない

等が必要となります。

Web会議のマナー

1ヵ月半程Web会議を利用してみて、会議を円滑に進めるための注意点等を記載します。

  • Web会議開始前に事前準備をしておく
    会議を開始してから招待等を行うと、準備だけで10分/20分...と会議が遅延することがある為、事前に招待メッセージやURL等を共有しておくとをオススメします。
    ※可能であればWeb会議のリハーサル等を行っておくと良いです。

  • ハウリング対策
    マイクとスピーカーを近づけたり、その他機械とマイクを近づけたことでハウリングが発生するので近づけない様にしましょう。

  • 音声確認
    ネットワーク環境等の原因で声が届かないことがあるので、Web会議を始める前や発言する前に相手側にきちんと声が届いているか確認しましょう。

  • 自分が発言しない時は、マイクをミュートにしておく
    マイクが常時ONのままだと意外とノイズを拾い、聞き取りずらいので未使用時はミュートにしましょう。(ネットワークの負荷軽減にもなります)

  • 会議終了時の連絡
    Web会議では会議終了を把握しずらい為、終了する際はしっかりと締めると分かりやすいと思います。

まとめ

まだ、全ての機能を使いこなせていませんが上記3つのWeb会議を利用してみた感想は以下の通りです。

この先もしばらくテレワークが続くかと思いますが、目的や利用人数、機能等でWeb会議をうまく使い分けてみて下さい。