パイオニアにおける「オンプレミスからクラウドへの移行」を覆面対談で裏側までお話します！

はじめに

パイオニアではカーナビゲーション向けの通信機能やオンライン地図更新機能など数多くのサーバーシステムを運用しています。
今回はパイオニアで運用しているシステムがどのような遍歴でオンプレミスからクラウドへ移行したかを中心に、クラウド環境へ移行したからこそ取り組める、自動化、IaC化などの現在の取組みついて、実際にシステム運用をしているメンバーが語っていきます。

（IaC：Infrastructure as Codeとは、サーバーやネットワークをはじめとしたインフラの構成をプログラムのようにコード化し、その構築や管理を自動化する手法）

在宅勤務もすっかり定着したパイオニア、今回はオンライン＆覆面座談会形式でお届けします。

🟡M川
本日司会進行を務めさせていただきます、よろしくお願いします。

⚫🔴🔵一同
よろしくお願いします。

🟡M川
早速ですが、今回のテーマである【 オンプレミスからクラウドへの移行 】について話ができればと思います。

システムの集約と仮想化

🟡M川
2010年当時に社内で事業系サーバシステムの開発、運用を行う組織が出来ましたが、今回集まってもらったメンバーはその頃からサーバーシステムの保守運用に関わっているメンバーですね。

🔵KN
当時はまだオンプレミスのサーバーが主流でしたが、システムごとにデータセンターが分かれおり運用体制もバラバラでした。まずはそれらのシステムをパイオニアの自社データーセンターに用意した仮想基盤に集約することから取りかかりました。

⚫K田
システムを仮想化するというのは今では当たり前ですが、物理サーバーで動いているシステムを仮想化して移設することは、当時はチャレンジングな取り組みでしたね。この取り組みによりパイオニアの事業系サーバーが1つのデータセンターに集約され、インフラ、保守、運用コスト面でかなりの最適化が図られたなと思います。

🔴N山
当時はまだOSもシステムごとに違ったり、UNIXサーバーや、Linuxサーバーなど機材についてもバラバラでした。

🔵KN
あるデータセンターでは、サーバー台数が200台以上の規模で、もうサーバーのラックも増やせない状況でしたので、このデータセンター集約の前にVMWareを使ったサーバーの仮想化にも取り組んでいました。
当時は商用環境に導入するのは社内でも賛否ありましたが、そこでトライアル的に導入した技術が、データセンター集約においても活用できました。

🟡M川
その他に苦労した点としては、データセンターが首都圏で広範囲に点在していたことですかね。

⚫K田
移設のときは必要な機器を自分たちで車を運転して移動させたり、データの移動を人手で行うのでタクシーで搬送したり、クラウドが主流な今ではなかなかあり得ない苦労がありました。
じつはDCの移設はかなりの数を実施してまして、社内に移設のプロが複数名いました。ここにいる🔵KNさんもです（笑。

オンプレミスのシステム運用

🟡M川
そんな感じでデータセンター集約はできたものの、仮想サーバを動かす基盤はパイオニアで管理するオンプレミスのサーバーであり、そのハードウェア保守・メンテナンスは引き続き運用の重荷になっていましたね。

⚫K田
夜間休日問わずハードウェア障害は発生するので、よくデータセンターに入館してハードウェア障害対応作業など行っていました。

🔴N山
ネットワーク機器の設定変更はリモート対応ができないできないものが多く現地作業が基本であり、データセンターへの入館が必要な作業も頻繁にありましたね。

🔵KN
当時はネットワーク機器を使った負荷分散を多用していました。ユーザーへの影響を考えて深夜にメンテナンスを行うことも多かったですが、お客様が使っていない時間帯なので各サーバへアクセスをさせるために自車で実走行して、アクセスログを出しながら正しく動作するか確認したこともあった。今となってはいい思い出です（笑。

⚫K田
当時は、GW、お盆休み、正月の休みは本当に憂鬱でした（笑。
皆さんが車に乗ってたくさんお出かけすると、想定以上の負荷があり、特定の時間に負荷が集中するなど対策で追われてました。
今ではシステム化できて手放しで運用できています。

🔴N山
オンプレミスで苦労した点で他には、東日本大震災の時に、当時移設先の環境がオフィスの近くだったので、心配して🔵KNさんと二人で見に行ったら、まず建物の主電源が落ちていてエレベーターが使えず、階段でビルの上層階まで登り、フロアについたら当時のビルは免振構造のビルだったので、上層階が大揺れしてて、免振ラックが少し傾いていてびっくりしました。

🔵KN
当時はまだデータセンター集約を開始したばかりの時期でしたが、サービスイン前だったので、そこのラック内のサーバ数百台を全てシャットダウン対応したり、計画停電もあったので、移設の実施計画が一ヶ月ほど遅れる事態にもなりました。

IBMクラウドへのシステム移設

🟡M川
その後パイオニアの自社データセンター廃止の方針もあり、2016年頃からIBMクラウドへのシステム移設を行いました。
移設終了期限が設定されていたため、仮想サーバーをそのまま移設出来るクラウド環境という前提条件のもと、IBMクラウドのIaaS環境への移設を決定しました。

⚫K田
IBMクラウドへの移設は、今回ここに集まったメンバーとはまた違うメンバーを中心に行いましたが、課内で以前のノウハウを共有したり、作業を手伝ったりここにいる移設のプロ（笑）たちにも大いに関わってもらいました。

🟡M川
IBMクラウドのIaaS環境に仮想基盤を構築することで、自分たちでハードウェア保守・メンテナンスをすることからは解放されましたが、サーバーやNW機器などのインフラを管理することは変わりなく、維持メンテナンスのための管理コストは引き続きかかっていますね。

🔵KN
移設したIaaS環境は自由度も高い反面、それを管理するための専門的な知識やコストもかかるところが大変ですね。

🔴N山
いわゆる手軽に始められるクラウドという感じではないし、移設前のシステムをそのまま動かすという制約もあってクラウドのメリットを十分享受出来ていない面もあるのかなと思います。

AWSなどマルチクラウドの活用

🟡M川
最近ではAWSを中心としたPaaS、SaaS環境でシステムを構築することがパイオニアでも主流になっていますね。

⚫K田
AWSなどPaaS、SaaSを扱うようになって、これまであったようなインフラ起因のシステムの障害などは確実に少なくなってきました。
AWSの場合は独自の用語だったりスキルが必要だったり、新機能も増えるので日々情報のキャッチアップをしていく必要性を感じます。

🔴N山
私もSREエンジニアへの変革が必要になっていることは日々感じています。最近はIaCにも取り組んでいます。

🔵KN
そうですね。私達インフラエンジニアは、仮想化環境をやっていたとはいえ、オンプレミスの環境と大きくは変わらない技術で活動していたのですが、AWSなどはIaCで管理できるのでその能力が必須だと感じています。
今、猛特訓で勉強しながら進めています（笑。

🟡M川
セキュリティの技術についても、オンプレミス時代から大きく変わってきました。

🔴N山
セキュリティ技術においても、AWSなどのマルチクラウド向けのSaaSサービスを導入、セキュリティベンダーと協力し、一緒に活動しながら技術を勉強しています。

🔵KN
システムの負荷対策についてもオンプレミス時代から大きく変わってきましたね。
さきほども話が出てきましたが、当時はシステムの負荷対策には人為的なフォローが必要な時がありましたが、IBMクラウドでもコンテナ技術の導入を行ったり、AWSではAmazon EKSを東京リージョンでのサービス開始当初から導入するなどPaaS、SaaSサービスを活用できています。

⚫K田
システム全体としてもオートスケーリングを活用するようになってきており、負荷対策がかなり楽になりました。

🟡M川
あらためて振り返ってみると、この10年ちょっとのあいだでサーバ、インフラ技術は大きく様変わりしましたね。

🔵KN
そうですね、まだまだ技術の進歩は続くでしょうから、それに追従できるよう精進します（笑。

最後に

今回はパイオニアがオンプレミスからクラウドに移行する過程とSREエンジニアに変革していくメンバーの様子を中心にお届けしました。今後もクラウド環境でのSRE活動について記事を掲載していく予定ですのでぜひご期待ください。

パイオニアはマルチクラウド環境を支えるSREエンジニアを募集しています。最新技術を使ったインフラ環境の構築、運用に興味がある方は、ぜひ採用ページからご応募ください！