WMSを支える機器インフラの変遷 自社サーバールームからIDCとクラウドへ
物流ブログをご覧いただき、ありがとうございます。
当社は主なサービスとしてWMS（倉庫管理システム）を提供しています。
日々の物流現場で目にするのはWMSの画面や機能ですが、その裏側ではサーバーやネットワークなどの機器インフラがシステムを支えています。
どれほど高機能なWMSでも、土台となる機器やネットワークが安定しなければ、現場で使い続けることはできません。
入荷、保管、出荷といった業務を止めないためにも、インフラは物流と切り離せないテーマです。
今回は、当社が経験してきた機器インフラの変化をたどります。
2000年頃の自社サーバールーム、2012年に移行したIDC（インターネットデータセンター）、そして今後の利用を進めるAWS（Amazon Web Services）まで、何が変わり、どのような課題が残っているのかをご紹介します。
WMSの安定稼働を支える「機器インフラ」
機器インフラとは、システムを動かすためのサーバー、ネットワーク、電源、空調などの基盤を指します。
利用者からは見えにくい部分ですが、WMSが必要なときに動き、現場からアクセスできる状態を保つ役割を担っています。
物流現場では、多くの作業が連続しています。そのため、システムの停止はIT部門だけの問題ではありません。
機器の故障や通信の不具合にどう備えるかは、物流サービスを継続するうえで避けて通れない課題です。
2000年頃は自社サーバールームで機器を管理
2000年頃は、企業内でもネットワークが広く使われ始めた時期でした。
当時は自社内にサーバールームを設け、汎用機やWindowsサーバーなどを置く構成が主流でした。
サーバールームでは、機器を冷却するために空調を常時稼働させていました。
室内に入ると、冷房の風と機器のファンが発する大きな音に包まれます。現在の静かな執務環境から振り返ると、機器を社内に抱えていた時代ならではの光景です。
機器の保守も障害対応も自社で抱えていた
当時は、各機器を自社で一つひとつ管理し、必要なメンテナンスを手配しなければなりませんでした。
落雷や電源障害が起きると、システムの提供へすぐに影響が及ぶおそれもあります。
汎用機に障害が発生した際はベンダーへ連絡し、丸一日かけて修理することもありました。
交換用の機器や部品をバイク便で送ってもらい、到着を待ちながら復旧に備えた経験もあります。インフラを維持するために、人と時間を大きく割いていた時代でした。
2012年にIDCへ移行し、障害への備えを強化
2010年頃になると、IDC（インターネットデータセンター）という設備が整い始めました。
IDCはサーバーやネットワーク機器を設置し、運用するための専用施設です。電源設備を強化しやすく、メンテナンスを担う要員も確保しやすい環境が整っています。
当社も2012年にサーバー類をIDCへ移しました。自社サーバールームで抱えていた電源や保守の負担を軽減できたことに加え、サーバー類を冗長化し、障害が起きても別の機器で動かせる構成を取りやすくなったことは大きな変化でした。
復旧までシステムが止まり続けるリスクを抑えられるようになり、運用を担う側の心理的な負担も軽くなりました。
機器の音が響くサーバールームを社内に置かなくなり、仕事場の静かさを改めて実感したことも覚えています。
IDCへの移行は、設備面だけでなく、日々の働き方にも影響を与えました。
IDCで改善した後に見えてきた新しい課題
IDCによって多くの問題は改善しましたが、すべてが解消したわけではありません。
停電対策が施されていても、広い地域に及ぶ停電ではサービスを提供できない事象が発生することがありました。
機器は使い続けるうちに老朽化します。システム全体を刷新する時期が来ても、大規模な機器構成ほど移管作業は複雑になります。
安定稼働を支えてきた設備が、次の環境へ移る際には大きな壁になることもあります。
これからのインフラとしてAWSの利用を進める
当社がこれからのインフラとして利用を進めているのが、クラウドコンピューティングサービスのAWSです。
クラウドでは、物理的なサーバーをあらかじめ自社で購入して保有する形に限らず、必要なITリソースを必要に応じて利用できます。
AWSを活用する利点の一つは、必要な分から始め、負荷や要望に応じて規模を変えやすいことです。
従来は将来の利用量を想定して機器を事前に用意していました。クラウドでは、まず小さな環境で導入テストを行い、実際の負荷を確認してから必要な大きさへ変更する進め方を取りやすくなります。
当社でも、最小限の構成で準備とテストを行い、機器の負荷状況に応じてミドルサイズへ変更することで、初期コストを抑える取り組みを進めています。
最初から大きな機器構成を用意するのではなく、実際の利用状況を見ながら調整できる点は、クラウドならではの柔軟さです。
地理的に離れた場所を使う冗長化も視野に
AWSには、リージョンやアベイラビリティーゾーンと呼ばれる複数の物理的な拠点があります。
構成を適切に設計すれば、東京と大阪など地理的に離れた場所を使って冗長化することも可能です。当社でも将来的な利用を想定しています。
ただし、クラウドを利用すれば自動的に停止しないシステムになるわけではありません。
どの場所に何を配置し、障害時にどのように切り替えるかは、サービスに求める水準に合わせて設計する必要があります。
クラウド移行は機器を置き換えるだけではない
クラウドへの移行は、既存のシステムをそのまま別の場所へ移すだけではありません。
現在のネットワークインフラを見直し、サービスを止めずに新しい環境へ切り替えられるシステムを構築する必要があります。
長く運用してきたシステムほど、現行の機器やネットワークとの関係が複雑になっています。
小さな環境でテストし、負荷を確かめながら規模を調整できるクラウドの利点を生かしつつ、移行の順序や切り替え方法を慎重に組み立てていくことになります。
乗り越えるべき課題は少なくありません。それでも、老朽化した機器を抱え続ける負担や、特定の場所に設備が集中するリスクを見直すために、クラウドへの移行を一歩ずつ進めています。
物流を止めないため、見えない基盤を整えていく
機器インフラは、物流現場から直接見えるものではありません。
しかし、WMSを安定して使い続けるには欠かせない基盤です。自社サーバールームからIDCへ、そしてクラウドへと環境が変わっても、この役割は変わりません。
インフラを変える目的は、機器を新しくすることそのものではなく、物流サービスを止めず、安定して提供し続けることです。
障害への備えを強め、運用する人の負担を減らしながら、変化する業務量にも対応できる環境を目指します。
