Mattermostを利用する
今回は、Mattermostを用いてチャット環境の構築をしてみました。
企業にチャットを導入したい！これは多くの方が感じていることだと思います。でも、LINEだと情報漏洩が心配だし、ビジネスチャットだと運営会社の管理が心配…。 それなら、自前で立ててしまいましょう！
いままでチャットがある環境が当たり前だったので、かる～い社内連絡にもメールをいちいち打つのがめんどくさいなあと感じます。 特に社内メールの中途半端なフランクさには未だ慣れない…。
メールで時間かかること
- 後から編集できないので、何度も何度も見返さないと気が済まない
- ひと目で分かる件名を考える（結構難しい）
- 宛先に漏れがないか確認する
- BCCに自分が含まれているか確認する
果たして、この作業って必要なのか？ 〇〇様、△△様って、メンションで良くない？ 人の名前間違えるの怖すぎ！相手が自分で登録しておいてくれればいいのに！と思ってしまうのです。
まあ！チャットなんてゆとりィ～！と思われるかもしれませんが、仕事の効率化には必須だと思います。もちろんセキュリティ面については考えています。
もちろん、チャットにしたって宛先とかに注意するのは変わらないけど、もっと！スピーディに物事を進めたい。
企業へのチャット導入のメリット/デメリット
5人程度が利用する検証環境であれば、「t2.micro」で足りるかと思うので、1年間の無料利用枠が残っている方は、無料で構築・利用できるかと思います。 ざっと思いついた範囲でメリットを示します。
ミスの防止
口頭連絡に依るミス防止 指示が明文化されるため、再確認する手間が省ける
対外的なメール誤送信の減少 社内連絡用（チャット）と、対外連絡用（メール）を使い分けることにより、メールの絶対数を減らすことができ、誤送信のリスクを減少させる
宛先の指定漏れの防止 予め作成したチャンネル内で発言をすることにより、CCに含め忘れるといった連携漏れがなくなる
スピードのあるコミュニケーション
連携ファイルにパスワードを掛ける必要がなくなる メールでファイルを連携する場合は、いちいちパスワードを作成して、暗号Zip化してという作業が必要だったが、社内利用専用であり、クローズドな環境のためその必要がなくなる
電話取次ぎの手間削減 在席/離席のステータスが表示されるため（多少のラグはあれども）、電話を何度もかけ直す必要がなくなる
どのデバイスからもアクセスが可能 専用のアプリケーションを入れることにより、iPhoneからも利用可能。外出先だとメール文章の作成に時間がかかり後回しにされがちだが、一言のメッセージで連絡できるため対応が早くなる
ここからはデメリット。個人的にはあまりないように感じますが。
導入コストがかかる
教育コスト 問い合わせが増えそう。ヘルプデスク業務の増加については覚悟が必要と思います。
費用 利用人数にもよりますが、月￥1000～￥2000くらいはかかると思います。
あとは、チャット上にバンバン添付ファイルつけると、すぐにサーバが逼迫すると思います。AWSの良さはコストの最適化にあると思うので、ファイルサーバ等がある場合はファイルの連携はそちらを利用して、チャットではフォルダパスのみを送り合うなど、運用ルールの徹底が必要です。
Mattermost
Mattermost（またーもすと）を推します。
「My Mattermost」のように、二次的にSaaS形式で提供されているサービスもありますが、AWSというインフラサービスがある以上、月額使用料等のコスト無駄と考え、自前で立てることにします。 Mattermostはオープンソースで公開されていますから、少しでもコストを最小限に抑える努力をしなくてはいけませんね。
シングルサインオン
Mattermostは、LDAPはもちろんのこと、ActiveDirectoryユーザとも連携が取れるので、管理も楽です。 WindowsでもLinuxでも連携が取れるなんて、なんて素敵なんだろう。
先日、社長にシングルサインオンの良さを説いたのですが、あまり通用しなかった^^; SNSの例えを出したのが悪かったのかな…。
社長にシングルサインオンの良さを説いたけど、あまり理解してもらえなかった… もちろんパスワード漏洩とかのリスクはあるけど、たくさんあるパスワードを一元管理できることの何が便利か分からない！って言われちゃうとなぁ。ソフトウェアの選定も、設計も構築も簡単じゃないのよ。 #SSO #社内SE
— Meihon@インフラエンジニア (@Engineer_Meihon) 2019年2月22日
全部の認証を同じパスワードに設定している人には、シングルサインオンの恩恵がわからないような気もします。 同じ認証情報でもセキュアに通信できる仕組みを予め提供することが、インシデントを減らすと私は信じています。
ちゃんとシステムごとに違うパスワードを設定しても、PCに付箋でパスワードを貼られたらたまったもんじゃない！ おじいちゃんとか、パスワード忘れてリセットの依頼とか出してくるし。
構築環境
今回構築するMattermostは、AWS上のプライベート環境に構築しています。
構成図
ざっくりと構成はこんなイメージです（IPアドレスは適当に振ってます）。
- 黒矢印：ユーザによる利用の流れです。VPN認証後Mattermostが利用できます。
- 赤矢印：構築や管理サイドでの流れになります。
構成の説明
本MattermostサーバはLinux上に構築しているため、セキュアにSSH接続するのに「Bastion Server」（踏み台サーバ）が必要となります。
インターネット上にあるMattermostのパッケージを取得するため、構築時には「VPC NAT Gateway」を通してインターネットに出ていく必要があります。このNAT Gatewayは思ったより課金が発生するので私は接続が必要になったら構築して、利用が終わったらその都度壊しています。※Elastic IPの開放も忘れずに。
VPNサーバには「Elastic IP」でグローバルアドレスを付与しています。 理由としては、起動のたびにIPが変わるととても面倒だからです。 「Elastic IP」は特殊な課金形体を採っており、割り振った対象が停止している間課金が発生します。IPアドレスの無駄遣いを避けるため、使用していないのであれば開放してね！と言う意味だと思います。
Bastion Serverには、グローバルアドレスを直接割り振っています。 管理用サーバなので起動している時間が短いし、起動毎に動的に採番されても運用上特に問題はないと思います。
具体的な構築方法についてはこちらを参考にさせていただきました！ sig9.hatenablog.com
