ソフトバンクの携帯電話部門のシステム系エンジニアは何している?

執筆日:

更新日:

内容自体はもうかなり過去の話なのです。 2年くらい前まで、携帯電話キャリアの中のエンジニアをしていたのですが、いまでもよくどんなことしていたの?って聞かれます。
確かに、携帯電話キャリアの中にエンジニアがいるイメージはあまりありませんし、いたとしてもベンダーコントロールの業務のイメージが多いと思います。
今回は、自分の備忘録もかねて、どんなことをしていたのかみなさんのイメージを変えるためにもまとめておこうと思います。

前提

2013年当時の名前で「プラットフォーム運用本部 運用ソリューション開発部」というところにいました。約3年半いました。 プラットフォーム運用本部というのが、携帯電話の基地局や携帯電話のコアネットワークの監視運用している部門です。 運用ソリューション開発部というのが、監視運用業務を効率化するためのシステムを作って提供している部門です。 その中でも自分は、フェムトやリピーター、屋内基地局と呼ばれるタイプの監視システムとその周辺業務システムを担当していました。

先日、公開されていましたが携帯事業の人員を4割削減して新規事業へ人材の配置転換をするとでていましたが、 実はこの動きはもっと前から始まっていて、自分の部署はまさに携帯部門の人を減らすための仕組みづくりを行っていましたし、自分はその後に新規事業の本部へ異動になっているのでまさにそのルートという感じである。

参考: ソフトバンク孫社長「国内通信、人員4割 配置転換目指す」

やったこと

トータルすると、よくあるエンタープライズ企業のシステムの内製化を実現するべく、 内製でのシステム開発から、その組織づくりの役割として動いていたというと収まりがよさそうです。

開発環境としては整備されている状態では全くなかったので、地味なところまで自分でやっていたところはありました。
この職場のよかったところは、こういった仕組みづくりを上からの指示でやっていたわけではなくて、
自らが課題だと感じそれをチームをあげて実行させてくれたことだと思っています。
(もちろん好き勝手できたわけではなくメリットを伝えつつ、承認を取ってです)

逆に言うと、当時は組織として内製できるエンジニアを採用して専門に配属していたわけではないので、苦労する面も多かったです。

全体像

全体像を示しておきます。読み進めていくうえでこちらを見ておくと読みやすいと思います。
簡略化して書いていますが、実際にもっと雑多なシステムもたくさん持っていて、担当していたのは20システムほどでした。 サーバ環境はオンプレです。モバイルネットワークは法的な理由で基本すべてオンプレです。

overview

統合的な基地局管理システムと周辺業務システム

概要

この部隊の一番のミッションは、モバイルのネットワークの運用している人たちが楽をするための仕組みを作ることです。 複数ある携帯電話の小型・屋内基地局を統合的に管理するものや、基地局の情報を閲覧するためのものなどの業務アプリケーションを開発していました。 基地局のステータスの確認や制御コマンドの発行、基地局からのアラート管理、アラートに対する自動対応機能など備えていました。

なぜ必要だったか

あまりイメージがわかないかもしれませんが、携帯電話の基地局も日々新しいベンダー・種類のものが導入されていきます。 基地局ベンダーは基地局を制御・監視するための専用のクライアントを用意することが多いです。 一方、クライアントが増えると基地局運用者は運用が難しくなるので、統合管理ツールや基地局運用を自動化する仕組みが必要になってくるわけです。

また、日々増加する基地局にともない、アラートもどんどん多くなります。 運用人員を増やせないので、ある程度定型化されている運用については自動化し、基地局復旧の自動化を実現していました。

技術的なところ

いくつかのシステムに分かれているのですが、一般的なPHPやRubyで書かれたWebベースの業務システムです。
Webベースの業務システムということで、実装が難しいというよりその業務設計とそれをシステム化する部分が特に難しかったです。 技術的な工夫としては、ちょうど下でのべる「基地局制御APIサーバ」が該当します。

基地局制御APIサーバの構築

概要

各基地局ベンダーのシステムへの基地局制御のコマンドをRESTful APIとして実行できるAPIサーバの構築。

なぜ必要だったか

各基地局ベンダーが用意する監視制御システムは、簡単に使えるRESTful APIなどなく、 外部アプリケーションに基地局制御の機能を実装するのは難しい(面倒な)状態でした。 例えば基地局を制御するコマンドを実行すると同期的に処理が走るものもあり(かつ実行時間が長い)、各アプリケーション側で処理の結果を待つ、あるいはジョブキュー形式にする必要がありました。 また、基地局を制御する外部アプリケーションが増えると制御のバッティングなど発生するようになり課題が生じていました。

技術的なところ

上にも書きましたが、基地局を制御するコマンドを実行すると同期的に処理が走るものもあり(さらに実行に時間がかかる)、 各アプリケーション側で処理の結果を待つ処理を実装したりしていてアプリケーションの開発がむずかしくなっていました。 そのため、ジョブキュー形式を採用した非同期型のAPIも取り入れたことや、基地局制御という重要な処理を行うため、コマンドの生成にはテスト駆動開発を採用して品質を高める工夫など行いました。 (TDDについてはあるいみトライアル的な試みでしたが、コマンド生成というテストを書きやすいものだったこともありよいトライアルだった気がします)

基本的に、各基地直ベンダーの監視システムへのCLIコマンド実行をRESTful APIでリモートから実行できる仕組みなのですが、コマンドの種類によって非同期処理とするか同期処理とするかといった工夫をしました。ちょうどそのころ、クラウドインフラのAPIを使っていたので参考にしたのですが、例えばインスタンスのステータス取得は同期処理で、インスタンスの立ち上げや・スペック変更などは非同期処理でとあるように、使い分けすることで利便性をあげました。

api

共通リバースプロキシ

インターネットから利用できるようにするために、いわゆるDMZなネットワーク領域にWebサーバなどを配置し、アプリケーションサーバやDBを内部のネットワーク領域におくようなことをしていました。 しかし、他のチームなども含めインターネットから利用するシステムがどんどん増加していった背景があり、 DMZの物理的な限界もあるため、共通のリバースプロキシサーバを構築することにしました。

技術的なところ

「共通〇〇」を構築することは時には、設定の変更など申請とその設定反映に時間がかかって組織の開発のボトルネットとなることもあるかと思います。 今回物理的な制約で共通のリバースプロキシを構築せざるを得なくなりましたが、それでもリバースプロキシの運用側の負担を少しでも減らせるように、設定の変更依頼とその反映を自動化させるフローを整えました。 そのほか、共通基盤なので、可用性についての重要性が増してきました。 Corosync+Pacemakerを利用しHAクラスタを組むのにトライしました。

リバースプロキシにはNginxを採用しましたが、そのころにNginxは今までのApacheと何が違うのかなど興味をもって下記をまとめたりしていた。

base-image

開発環境、サーバプロビジョニング環境の改良

概要

乱立していた、開発環境やサーバプロビジョニング・デプロイ方法を統一化し自動化を実施。

なぜ必要だったか

開発を進めていく中で、下のような課題がでてきていました。

  1. リリースや設定変更作業に対して手作業で行っており、ミスの多発や時間が非常にかかっていた。システムが多くなるにつれてますますひどい状況になっていった。
  2. 開発環境と本番環境の環境差分により、デプロイ後の切り戻しが何度も発生
  3. 大小さまざまなシステムを扱っていたため、リソースの効率利用が必要になってきた

技術的なところ

実際には、はじめから紹介の状態にしていたわけではなく、試行錯誤の中でこうなりました。 まず、手作業での作業についてAnsibleにて自動化を図りました。 Ansibleで自動化しても、その実行元が異なると当然いろいろと問題が発生します。 また、全システム共通で仕込んでおきたいツールやバッチ処理などもあり、「共通ベースイメージ」を作ることにしました。 こちらを作ることでVagrantやKVMなど異なる仮想環境でも環境差分を可能な限りなくすことがきでました。 物理サーバの場合はイメージではなくKickstartなどを使って同じ環境を作るようにしました。

共通ベースイメージには、最低限のLinuxユーザの作成や各個人のSSH-Keyの配布するためのバッチ処理などを組み込んでいました。

base-image

また、Ansibleは基本的にSSHを使ってリモートサーバに接続しますが、踏み台サーバ越しに実行する場合の鍵の扱いや、実行速度について困っていて下記のような調査を出しながらプロビジョニング環境の整備など行っていた。

横展開

実は、こちらの仕組みと取り組みによって、自分のチームはうまく開発に集中できるようになって、部署全体として注目されることになりました。その後、こういった取り組みに対して他のチームでも実現できるように横展開したり組織への貢献もしていくことになりました。

さいごに

上記はどちらかというとプロジェクトベースでまとめましたが、そのほかにも外注システムの改修などでベンダーコントロールなどもたくさんおこないましたし、インターン学生の受け入れやうまくいった手法の他チームへの横展など幅広い視点で働かせてもらいました。
当時、新規事業の部署へ異動したときのブログにはもう少し広い視点での内容がかかれています。
参考: 社内システム開発からパブリッククラウドの会社へジョインします

記事の内容に関連した相談、仕事依頼したい New

記事の内容やクラウドネイティブ技術に関する相談、仕事依頼を開始しました。
仕事依頼、相談をしてみる

フィードバック

本記事に対して、フィードバックあればこちらのフォームからご記入ください。
記事の内容にフィードバックしてみる

このエントリーをはてなブックマークに追加