※ 本掲載記事は適宜アップデートされる可能性がございます。予めご了承ください。

物理NASを廃止してクラウドストレージを利用したい。

Google Cloud Storage を利用したい。

物理NASの運用自体を完全に撤廃したい。

そのようなご要望から本件は進展しました。

リモートワークが主流となった環境、海外拠点からのアクセスもしたいなど、その様な傾向が増えてきた時代背景も有りますが、事務所内に固執してデータを抱え込む必要が無くなってきたような現実的な状況があります。

業務が成り立つことが前提となりますが、効率化を考えると完全なクラウドストレージ化も得策です。

大きな容量のデータをやり取りするような業務が主流となる場合、ネットワーク環境に足を引っ張られてしまう可能性も否めませんが、数GB程度のファイルが主流の場合はそれほど大きな問題にもなりにくいと言えます。
安全性の観点からもほぼ問題はなく、むしろ物理NASを抱えているよりも安全性が高いとも言え、今の時代に取るべき手段でしょう。

Google Cloud Storage は当社でも運用中です。

ごく一般的な解釈では、安易に使える Dropbox を代表としたクラウドストレージサービスの取っ付きやすい構成からは比べるまでもなく高機能であり、さっと使いこなせるレベルのサービスではありません。

Google Cloud Platform 自体の根幹を把握することや、IAM（Identity and Access Management）の構成、それらにまつわる仕組みを把握しなければ使うことは難しいでしょう。

しかしながら、高機能なサービスを比較的安価で運用できるといった事があるため、組織など複数人でのきめ細かな運用を行うには有用な仕組みであると言えます。

データ保全、共有、高可用性、運用コスト、将来的な展開、等を考えた場合に、Google Cloud Storage の仕組みを運用することは正解の一つとも言えるでしょう。

データをどの様に扱うか、扱われているか。

これを実績ベースで想定することが Google Cloud Storage を運用する前に考慮すべき重要な設計ポイントです。

例えば、下記のような業務を想定します。

• 映像ファイルを複数人で共有しながら編集している

これらを想定すると、Google Cloud Storage を使うのはあまり得策ではないかもしれません。

とても単純な例ではありますが、「映像ファイル」という大容量ファイルの想定は、数十GB、ひょっとすると数百GB、にも達するファイルになります。

これらを複数人で共有して編集、といった事を行うとどのようなことが起きるでしょう。

• 初めに一人が Google Cloud Storage へ映像ファイルをアップロード
• 二人目が Google Cloud Storage から ダウンロード
• 二人目が編集して Google Cloud Storage へアップロード
• 三人目が Google Cloud Storage から ダウンロード
• 三人目が編集して Google Cloud Storage へアップロード
• （人数分続く・・・・）
• 四人目が Google Cloud Storageから ダウンロードして視聴

複数人で同じデータを共有できるメリットはあるものの、ダウンロード にかかる料金はデータ転送ごとに発生します。

スマホでいう、ギガの料金が別途かかってくるイメージに近いものがあります。

簡単にまとめますと、容量の大きいデータを多人数で共有して利用する場合には、運用コストが高くなる可能性があるということになります。

しかしながら、これらも考え方次第ではありますが、
例えば、Dropbox の最上位プランである Business Plus を選択しても、保存容量以外のハードルがあります。

そのハードルとは、 帯域制限がかかってしまうことです。そして残念なことにそれらは明記されていません。

当社の経験からしても、これら容量の大きいファイルを頻繁にやり取りするような使い方では、転送途中で帯域制限がかかってしまい運用がしづらくなる、といった始末で往々にして発生することだと想定されます。

Dropbox では、使いやすさとしてのメリットは有るものの帯域制限の閾値が Google Cloud Storage と比べて明らかに低いことは問題の一つとも言えるでしょう。

Google Cloud Storage で上述の大容量のファイルとは反対に、小容量（〜数MBなど）のフィアルを取り扱う一般的な使い方でも、同様にダウンロード にかかる料金はファイル容量に比例してかかってきます。

小容量のファイルを保存しておき必要な時に他の人がそれらを閲覧する、といった使い方が多くのケースでは当てはまるため、それほど ダウンロード にかかる料金を気にする必要はないかもしれません。

Google Cloud Storage は、取り扱う人数が多ければ多いほど、その分の ダウンロード にかかる料金が事細かにかかってくる仕組みです。

厳密には、データ処理に関する料金、オペレーションにかかる複雑な料金テーブルが設定されています。

人間が行うオペレーションに関しては試算が難しいのですが、実績ベースでは想定を下回る料金が計上されるケースが殆どです。

このように、データの特性から事前にある程度の試算は行えますので、保存したいデータの特性を見極めて行くことが重要である、という点をご理解いただけるのではないかと思います。

実際に、Google Cloud Storage を利用しようと思った場合、現時点ではWebブラウザ、もしくは接続用のクライアントアプリケーションが別途必要となります。

複数のアプリケーションがある中で、一般的には、Google Cloud Storageへの接続、安定性を考えると、Mountain Duck アプリケーション一択といった事になるでしょう。

その他、gcsfuse といったCLIベースでの接続方法も有ります。開発者向けではありますが、実績ベースでも動作確認が取れているため有効です。 カメラワークによるストレージ運用（その１） をご覧ください。

どうしてもMountain Duckアプリケーションのライセンス費用を払いたくないなどの場合はそれらの方法、もしくは利便性は下がりますが、Cyberduck（フリー版）を使う方法があります。

Mountain Duck はとてもシームレスにOSレベルのファイルマネージャー（Windows エクスプローラー、Mac Finder）と同化して動作します。

あたかも、自身のPCにそのファイルが有るかのように動作しているように見えるのは、キャッシュの仕組みが有るからに他なりません。

クラウドストレージサービスを利用するクライアントアプリケーションは、この様な仕組みになっている事により上述した ダウンロード にかかる料金の削減などにも貢献しています。また、軽量なファイルを扱う分には、大きな問題は発生しにくい状態となっています。

ふと忘れて、自身のPCにそのファイルが有るかのように動作してしまうので、その点だけ気をつける必要があります。

あくまでもネットワーク越しに操作しているファイルで有ることをお忘れなく。

※　当社の検証では、Mountain Duck で Google Cloud Storage への接続を行った際に、バケットへの接続は問題はないものの、フォルダレベルでのアクセス権をうまく継承していない事象を確認しています。バージョン4.16.0 (22153)

ネットワーク環境に依存はするものの、シームレスなファイル保存、管理が行えます。

複数人数での操作、またディレクトリ連携により組織やその他権限を振り分けたい場合なども柔軟に行えます。

ストレージクラスによる料金設定、ライフサイクルの指定でAutoclass機能によるストレージ費用の最適化は目玉となる機能でしょう。そして最安クラスである Archiveストレージからの取り出しも瞬時に行えるなど、AWS S3 には実装されていないメリットであるとも言えます。

また、デュアルリージョンバケットによるデータ保持領域の分散化、バージョニング、不意の削除時にもスムーズに復元が行える、などあらゆる方向からデータを守る構成です。

手軽さだけは引けと取ってしまうものの、総じて高機能な Google Cloud Storage のクラウドストレージを利用しない手はないでしょう。

これらの運用をご検討中の中小企業様は、上記の実績例をご参考に、当社宛てにお問い合わせください。

NASを廃止してクラウドストレージを利用したい。

運用中のNAS（Synology）をバックアップをしたい。

最近では、クラウドストレージサービスの認知度が向上してきたこともあり、警戒感なくストレージ運用を希望される方が増えてきました。

特に、複数人数でデータを取り扱う場合には自身のPCに保存したファイルのみを管理しているのでは、メールで転送するか、USBメモリーに保存して受け渡すなどが必要となり適切ではありません。

そのようなやり方は過去のお話になってきており、何某かのストレージ運用を行っているのは当たり前の時代になってきました。

それでも、目の前にあるPC、ハードディスクにファイルが保存されていることへの安心感が優先され、NASを手放せないのは誰もが味わっている感覚でしょう。

そして、Dropbox等の手軽なファイル共有サービスを使い始めたりなどするわけです。便利なサブスクリプション形態ですが、実はそれらは意外と高額であったりします。

手軽なファイル共有サービスも利用の仕方次第では十分な場合も多く、Dropboxを利用するのも一つの手段であると思います。

いろいろなサービスが有りすぎてよく分からないまま放置している最中に、事故は突然にして起きます。

自身のPCが突然クラッシュしてしまう、NASにあったデータが誰かに消されてしまうことを想像してみてください。

データ復元サービスなども有りますが、それなりにお高い勉強代を支払うことになります。これに頼ることは費用対効果を考えるとあまり得策ではありません。

また、日々の業務に追われ、手短にどこかにバックアップを取っているスタイルは時系列で意味のない状況になりがちです。（要するに、忘れてしまう）

通信環境も高速化してきている中で、クラウドストレージ側へ冗長化を図るのに、それを選ばない手はないという時代になってきています。

Google Cloud Storageであれば、ライフサイクル、マルチリージョンとしての運用、削除時の復元など、豊富な機能でデータを確実に保持できます。

オフィスにNASを設置してその隣にバクアップ用の外部ディスクを置いている、といった状況があるとしたら（よくある光景）、それとを比べますと雲泥の差なのです。

心理的には「目の前の物理筐体にデータが有る」ということに安心感を抱きますが、実はこれが落とし穴であったりします。

もし、オフィスが災害にあったら、盗難されたら、などを考えるとキリがありませんが、データ損失という観点で考えるとPCオンリー、少し加えてNASのみ、といった運用では相応に脆弱な状態であるとも言えるでしょう。

オンプレミス環境にて運用中のSynologyは、筐体内部のDSMおよび各種アプリケーション（Snapshot、Hyper Backup等）によってあくまでもオンプレミスの状態でバックアップが稼働しています。

しかしながら、Synologyを設置している事務所内において万が一の不可抗力が発生した場合には何ら意味をなさない状態であることは誰が見ても一目瞭然でもあります。

特に天災等が発生した場合には、Synologyに保存されている大切な資産データが一瞬にして無くなってしまうというリスクがあり、その可能性は0ではないことを経営者、もしくは管理者は認識する必要があるでしょう。

もちろん、多くのSynology導入者が実施するであろうSnapshot Replication を使ったスナップショットの取得、Hyper Backupを使った外付けHDDへのバックアップ、これらはあくまでも単一筐体もしくは物理的にはその近辺に設置されるであろうハードウェアによるバックアップです。

Synology単一筐体に保存されているデータをハードウェアに依存しない形でバックアップをすることを目的とした場合には、その近辺（Synologyを設置している場所）以外にバックアップを行うことを設計すべきでしょう。

これまで利用していたDropboxから Google Cloud Storageへ切り替え、Cloud Syncによるバックアップをすることといたしました。

Cloud Syncアプリケーションは優れた機能を備えており、他の多くのCloudサービス（例えば、AWS）にも同様に接続が行えます。

Cloud Syncは設定自体も比較的簡単に行えます。

ただし、Google Cloud Storage側の設定に関する難易度は少々高いかもしれません。Google Cloud Platformのサービスをよく理解している必要が有るでしょう。

Google Cloud Storage側の設定（リージョン、ストレージクラスや、権限、ライフサイクルなど）を適切に施した上で接続します。

インターネット越しのデータ転送であるため、その転送速度はファイル容量とネットワーク帯域に依存はしますが、想像しているよりも堅実なバックアップが行えます。Dropboxに比べても早い転送速度が見込めます。

運用中のSynologyは順次Google Cloud Storage側と同期が行われるため、例えばSynology側で新規ファイルの作成、変更、削除、もほぼリアルタイムで見事に同期が行われます。

仮にGoogle Cloud Storage側でライフサイクルを2世代以上に保持するようにすると、上書き更新されたファイルでも過去の世代のファイルを救出したりすることも可能です。
これは、Snapshot Replicationで救出した方が手っ取り早いとも言えますが、同様な事がSynology筐体に依存しない形でも実現できます。

事務所の外に居る場合でも、他のPC端末からGoogle Cloud Storageに保存したデータを取得できます。
仮に不可抗力によって事務所内のSynologyが破壊されてしまった場合でも、最新のデータはGoogle Cloud Storage側にも保存されているとう環境を構築できます。

設定するリージョン次第では世界中のデータセンターへ分散バックアップすることさえも可能になります。

また、万が一Synologyに事故が発生しSnapshot ReplicationやHyper Backupでは救出が難しい状態が起きてしまった場合においても、Cloud Syncを用いてGoogle Cloud Storageのデータにより再同期（データ復元）を行うことができます。

Synologyをリカバリして工場出荷時に戻すような事になってしまった場合においても、復元可能なリソースが筐体に依存しない形で保存されている安心感は絶大なものとなるでしょう。

Cloud Syncの稼働によるSynologyへの負荷はそれほど高いものでは有りません。

24時間365日同期が行われるためリアルタイム同期を行う方がメリットが有るとも言えますが、Synologyへのアクセス状況、日中の稼働は避けたいなどの要望に応じてはこれらは調整可能です。（Cloud Syncのスケジュール設定により稼働時間を調整）

また、Google Cloud Storageの課金を注視していく必要もあります。

これは、アップロードには転送料金はかからないものの、ダウンロード（同期取得）には転送料金が発生するため、多くの同期先を想定した場合には総容量に応じて相応の課金が発生します。

また、リージョンやストレージクラスも慎重に検討する必要があるでしょう。

保険的な意味合いの強いCloud Syncによるバックアップですが、それでもこの保険料は決して高いものではないでしょう。

これらの運用をご検討中の中小企業様は、上記の実績例をご参考に、当社宛てにお問い合わせください。

社内ストレージの空き容量がほぼなくなってきたため、新しいストレージを運用したい。

また、Windows Active Directory を効率的に稼働させたい。

オンプレミス環境にて動作している Windows Server 上の Active Directory とストレージおよび、国産 NAS による社内環境のこれら2役を、Synology社のNAS（DSM）へ移行することといたしました。

当初懸念されたのは、Windows Serverのディスクに収められている大切な資産データの移行が無事に行えるか、また、Active Directory の挙動が Windows Server と同様な挙動が担保されるか、ということでした。

これらを実施する際に下記を念入りに検討する必要がありました。
・業務上必要なデータが1日（夜間）で移行できるか？ 
・Windows Active Directoryの挙動が、DSM上（Synology Directory Server）でも同じ様に動作するか？

また、Dropboxを絡めた運用（結果としてバックアップ状態で利用）も同時に行うことにしました。

Synology の設定は、SHR-2（Synology Hybrid RAID／Synology独自のRAID管理システム）を選択しました。
SSD 4TB x 4 = 16TB ある総ディスク容量が、これらの設定により、約7TB程度の総利用領域となりました。

実際の移行前に行ったシミュレーションでは、幾度かの検証失敗を繰り返しました。
・Active Directoryの切り替え時にWindowsクライアントPCからドメイン参加がうまくできない（ドメインは別名を設定）
・Dropboxへのデータ転送が想定していたより速度が出ずに、1日ではコピーが完了しない（総容量2TB程度）

Active Directoryは ネットワーク上にあるDNSサーバーも絡んでいるため、これらを正常化することでSynology Directory Server での動作を無事に行うことが出来ました。（問題の根本は、Synologyには特に有りませんでした）
およそ40台程あるWindowsクライアントPCも特に問題もなく認証できるようになりました。

Dropboxは社外で運用するデータを対象に利用する予定でしたが、2TB程度あるデータをコピーするのに相当な時間を要しました。Dropbox側でセッション数および受信帯域の制限があるはずですが、当時は数週間程かかったと記憶しています。
結果的に、Synologyの完全バックアップとして利用している状態ですが、Cloud Sync というアプリケーションがよく出来ており、ほぼリアルタイムに、Synology ↔ Dropbox間を同期してくれます。
この、Cloud Sync アプリケーションはDropboxのみならず、多種のパブリッククラウドストレージをサポートしています。（素晴らしいアプリケーションです）

Dropboxは、Dropbox Business Standardを契約しており現段階では5TBという巨大な容量が提供されています。
接続アカウントには、2段階認証を設定し、管理者権限を的確に設定します。
管理コンソールからはアクティビティも容易に確認がおこなえるため、定期的に確認をしておいたほうが良いでしょう。

また、Windows Server上にある資産データは、自作バッチファイル（ROBOCOPY）により共有フォルダ毎にコピーする手段を取りました。
運用移行前の検証期間では、1ヶ月ほどタスクスケジューラーでこれらのバッチファイルを実行し、Windows Server ↔ Synology間のデータ同期をするという手段を取りました。

資産データの移行（同期）が、Windows Server上にあるものと、Synology上に有るものをバッチファイルのログから同じであることを確認し、各WindowsクライアントPCでのドメイン参加の切り替えと、共有フォルダの切り替えを行いました。

また、Synologyには、Snapshot Replication を設定しました。
これは、ファイル削除を行った際など、Synology内にある過去のスナップショットから削除したファイルを復元させることが出来るため、設定を行ったほうが無難な運用ができます。
運用切り替え後にも、これらの状況は頻発していたので、行うべき設定かと思います。

簡単に要点のみを記載いたしましたが、
着手してからこれらSynologyへの運用が完全に切り替わるまで、相当な期間を要しました。

企業内のネットワーク環境、または取り扱いファイルの需要度にも依存するとは思いますが、確実な運用移行を行う場合には、慎重な検証が必要です。

結果として、Synologyを導入して良かったという評価をいただきました。

Synologyに限らず、他社のNAS製品も含めて年々機能強化を行っており、一昔前の製品とはまるで異なる製品になっています。

これらの運用をご検討中の中小企業様は、上記の実績例をご参考に、当社宛てにお問い合わせください。

運用中に発生した事象を記載する予定です。