前編では、Atlassian製品を安定運用するためのポイントを、
- 安定稼働できるプラットフォームの選定
- セキュリティ対策
- 運用監視（問題の早期発見）
- データ保全（バックアップ）
の4つに大きく分け、1番目の「安定稼働できるプラットフォームの選定」についてお話しました。後半では残りの3つを順に説明していきましょう。
セキュリティ対策
続いて「セキュリティ対策」についてです。まず、AWSなどのパブリッククラウド上でAtlassian製品を利用するには、次の方法が挙げられます。
- プライベートネットワークから利用する（Direct ConnectやVPNなどのプライベート接続経由でアプリケーションを利用）
- パブリックネットワークから利用する（インターネット経由でアプリケーションを利用）
これからパブリッククラウド上でAtlassian製品をお使いいただく場合、要求されるセキュリティによりますが、パブリックネットワークでの利用をお勧めします。
パブリックネットワークで運用するメリットとして、次の点が挙げられます。
- インターネット接続可能な環境があればアプリケーションを利用できる（専用線やVPNなど、特別なネットワークや設備を必要としない）
- アプリケーションの利用拠点の増減に対応しやすく、利用開始／利用終了が短時間で行える（セキュリティグループまたはリバースプロキシ上での、接続許可IPアドレスの追加／削除のみでアクセス制限が可能）
- 企業によっては、社内LANやプライベートネットワークのセキュリティポリシーを受けない（たとえば、協力会社にも同じアプリケーションを提供しやすい）
なお、パブリックネットワークでの運用に関しては、サーバへの不正侵入や、アプリケーションの改ざん、盗聴の可能性など、セキュリティ面のリスクを心配される方もいると思います。パブリックネットワークで運用する以上は確かにこのようなリスクが多少なりともあるかもしれませんが、通信経路の暗号化やアクセス制限を適切に行い、IDS／IPSで不正なトラフィックを検知／遮断することで、それらのリスクを可能な限り回避できます。また、脆弱性への適切な対応や、各種設定の定期的な見なおしなど、適切なメンテナンスを継続的に行うことで、よりセキュリティを高められます。これらを行うことで、オンプレミスやプライベートネットワークと比べて遜色のないセキュリティを確保できます。
運用監視（問題の早期発見）
続いては「運用監視」についてです。当社では統合監視ソフトウェア（ZABBIX）によるアプリケーション環境や運用基盤のリソースを監視しています。ログイン画面のレスポンス、プロセス監視などのサービス監視や、致命的なエラーのためのログ監視のほか、CPU使用率、ディスク使用率、メモリ使用率、ネットワーク使用率などを監視しています。
代表的な監視項目をまとめると表3の内容となります。
表3 代表的な運用監視項目
| 監視項目 | 通知 |
|---|
| ログイン画面のレスポンス |
- ログイン画面のURLへアクセスした際に、40x系や50x系のHTTPステータスコードがレスポンスとして返った場合
- ログイン画面のURLへアクセスした際に、URLに接続できない場合
|
| プロセス／サービス監視 |
- アプリケーションのJava Management Extensions （JMX）へ接続できない場合
|
| DBMS（PostgreSQL）監視 |
- DBへ接続できない場合
- スロークエリ数が閾値を超えた場合
- DBコネクション数が閾値を超えた場合
|
| MTA（Postfix）監視 |
- SMTPへ接続できない場合
- メールキューに滞留するメッセージ数が閾値を超えた場合
|
| CPU使用率 |
- CPU使用率が一定時間内に継続して閾値を超えた場合（アプリケーションのCPU使用率が高い場合、ディスクI/OやネットワークI/Oの高負荷によってCPU使用率が高くなった場合など）
|
| ディスク使用率 |
- ディスク使用率が閾値を超えた場合（ディスクの空き容量が少なくなった場合）
|
| メモリ使用率 |
- インスタンスの割当メモリの使用率が閾値を超えた場合（メモリの空きが少なくなった場合）
- JAVAヒープの使用率が閾値を超えた場合（JAVAヒープの空きが少なくなった場合）
- SWAPの使用率が閾値を超えた場合（SWAPが少なくなった場合）
|
| ネットワーク使用率 |
- ネットワーク使用率が一定時間内に継続して閾値を超えた場合（高トラフィックの状態が継続する場合など）
|
New RelicやDatadogなども組み合わせて利用する場合もあります。
このような監視状況をモニタで常に表示し、異常があったときにすぐに気づけるようにしています。
データ保全（バックアップ）
続いては「データ保全（バックアップ）」についてです。
Atlassian製品に限りませんが、AWSでアプリケーションを運用する際は、AWSの機能を最大限に活用することで運用を大幅に効率化できます。
バックアップに関しては、AWSにはEBSスナップショットというボリューム単位でバックアップする機能があります。EBSスナップショットを利用することでインスタンスを停止することなく、効率的かつ安全、低コストでバックアップができます。また、EBSスナップショットは世代管理に対応していますので、これも活用するとよいでしょう。
併せて、万が一に備え、AWSの機能に依存しない汎用的な手順によるバックアップの方法も用意しておくとよいでしょう。
EBSスナップショットと合わせて、ファイルベースのバックアップ（データベースのDUMP取得とrsyncによる別ボリュームへのバックアップ）も行うとデータの保全性をより高められます。たとえば、AWS側のサービス障害や実行スクリプトの不具合などによってEBSスナップショットが正常に行われていなかった場合、ファイルベースのバックアップが保険になります。
なお、当社の場合は、EBSスナップショットとファイルベースのバックアップの両方を行い、EBSスナップショットは3世代のバックアップを取得しています。
その他にも、弊社では行っていませんが、DRBDを用いてボリュームごとにレプリケーションする方法もあります。たとえば、AWSと西日本にリージョンの存在する他IaaS間でレプリケーションを行うと、災害対策（DR）として有効です。
最後に
このポイントをふまえたうえで、当社のクラウドサービスは、日本では数少ない「ISO27001（ISMS）とISO27017（ISMSクラウドセキュリティ認証）」を取得できました。
ISO27017とは、その適用範囲内に含まれるクラウドサービスの提供もしくは利用に関して、ISO/IEC 27017:2015のガイドラインに規定されるクラウドサービスの情報セキュリティ管理を満たしている組織へ与えられる認証です。JIS Q 27001:2014（ISO/IEC 27001:2013）認証を前提としており、取得した組織には認証ロゴが付与されます。
利用するユーザや格納するデータが増加し、企業の業務システムのサービス継続が重要になってきたときには、この記事を参考に堅牢なサーバインフラで運用することをお勧めします。
不安や心配がある場合は、当社の「RickCloud」サービスに丸ごとお任せいただければと思います。
米国Atlassianから、2年連続で
「Top new business APAC」を受賞。
Atlassianセールスパートナーとして
アジアパシフィックで1位の証
日本だけでなく、アジア圏でもアトラシアン製品販売のトップエキスパートであるリックソフトのWebサイトでは、各アトラシアン製品の体験版を提供しているほか、アトラシアン製品専用のコミュニティも運営しています。まずはアクセスしてみては！
- リックソフトJIRAデモ環境
- https://www.ricksoft.jp/demo/
- 第1特集
MySQL アプリ開発者の必修5科目
不意なトラブルに困らないためのRDB基礎知識
- 第2特集
「知りたい」「使いたい」「発信したい」をかなえる
OSSソースコードリーディングのススメ
- 特別企画
企業のシステムを支えるOSとエコシステムの全貌
［特別企画］Red Hat Enterprise Linux 9最新ガイド
- 短期連載
今さら聞けないSSH
［前編］リモートログインとコマンドの実行
- 短期連載
MySQLで学ぶ文字コード
［最終回］文字コードのハマりどころTips集
- 短期連載
新生「Ansible」徹底解説
［4］Playbookの実行環境（基礎編）
