はじめに

NTTデータ先端技術株式会社にてアジャイル開発並びに技術調査業務に従事している志田です。現在、私が実施している業務は顧客に提案するブラウザベースで稼働するインタラクティブアプリケーションの提案、技術調査から、大規模コーポレートサイトのクラウドアーキテクチャの検討、シングルサインオンの導入や3D地図の表示検証、AIの導入からデータ分析といった華々しいものから、ちょっとした運用スクリプトの作成、稼働しているシステムの定期保守といった地道な作業も担当しています。

エンジニアとしてさまざまなプロジェクトに関わるうちに自然と自身が担当する範囲も広がっていき、今では様々なプロジェクトに様々なロールで関わるようになりました。今回は公開できる範囲で特に私の転機となったプロジェクトと、そのプロジェクトを実施するうえでどういった点を意識していたかを振り返り、新しい技術にどう向き合っていったかを考えてみます。

アプリケーションエンジニアからクラウドエンジニアへ

2008年ごろだったと記憶していますが、それまで所属していた部署が解散することになり、別の部署に組み込まれることになりました。それまでの部署ではXP(eXtream Programing)を利用したアジャイル開発を推進する部署に所属し、先進性のあるアプリケーション開発を主にしていました。また、私自身は当時利用者が多かったJavaの開発ツールであるEclipseを使った開発ツールの拡張などを行なっていましたが、AWS EC2/S3が正式リリースされた直後で、クラウドを使ってみたいという思いがありました。

このため、部署異動を契機に当時の上司に「これからはクラウドが流行るはず、自分はクラウドがやりたい」と進言しました。当時の上司は部下の話をよく聞いてくれる方で、自分のクラウドをやりたいという思いを叶えるためプライベートクラウド構築のプロジェクトにアサインしてくれました。自分はその時、クラウドを使うプロジェクトをやりたかったのですが、思いとは裏腹にクラウドを作るプロジェクトになってしまいました。

  • アプリエンジニアとして習得していた技術とクラウドで新たに直面した技術

この時、評価・利用しようとしたプロダクトはEucalyptusというオープンソースソフトウェアで、広い意味ではアプリケーションではあるのですが、ソースコードを理解するためには以下の技術に対する理解が必要でした。

  • コンポーネント間の通信を行うSOAP/WSDL
  • 管理画面を表示するWebアプリケーション技術
  • ネットワークの分離を行うタグVLAN
  • ネットワークのアクセス制御を実現するためのnetfilter
  • サーバの仮想化のためのXen、KVM
  • ディスクの仮想化のためのLVM

この経験を通じて初めてインフラ、OSのレイヤーと深く向き合うこととなりました。実際にEucalyptusを利用してプライベートクラウドを構築しようとすると、アプリケーション開発では発生しない様々なトラブルに見舞われたことを覚えています。たとえば、タグVLANを利用するためサーバ同士の接続に機能豊富なネットワークスイッチを利用することができず、安価なスイッチで接続する必要があるケースや、ある時仮想マシンが起動しなくなった原因を追うとディスクアクセスのし過ぎでハードディスクが故障していたこともありました。

不慣れながらもこういった問題に直面するたびに一つ一つ原因を解析し、解決していくとインフラについても段々と慣れていくとともに、アプリケーション開発でもインフラ構築でも変わらない部分が見えてきます。ITの世界は非常にロジカルで、何かおかしなことが起こった場合に必ずその原因があります。アプリケーション開発だけを行なっていると問題の発生原因はほとんどソフトウェアのバグに起因するものとなりますが、インフラの場合は発生原因の範囲を少しだけ広げてハードウェア故障なども視野に入れる必要があります。ただ、突き詰めるとアプリケーションでもインフラでも同じようにある入力を受けて、入力内容を精査し、結果として出力するという流れになります。アプリケーションの場合はUIが入力を受けて、UIに出力を返すという形ですが、こちらでのクラウド制御ソフトウェアの場合はAPIやハードウェアの変化が入力になり、OSのコマンドで出力するという形に変わるだけだと捉えられます。

こうして自分で強く望んだわけではないですが、自然とアプリケーションエンジニアからインフラエンジニアへと転身していきました。

クラウドエンジニアからCMSエンジニアへ

他にも大きな転機となったプロジェクトがいくつかあります。上述のプライベートクラウド構築のプロジェクトをきっかけとして、順調にインフラエンジニアとしてのキャリアを積んでいましたがある日突然、他のプロジェクトの支援を依頼されました。そのプロジェクトはオープンソースのCMSソフトウェアであるDrupalを利用して社内向けポータルサイトを構築するプロジェクトでしたが、リリース間近で性能測定を実施したところ全くパフォーマンスが出ず、性能改善をして欲しいというものでした。

その時の上司になぜ自分が性能改善の支援をする人として選ばれたのかを聞きましたが、回答としては「インフラを知っている人は性能などにも詳しそうだから」という理由だったと記憶しています。

  • イメージ > インフラエンジニアとして習得していた技術とCMSの技術

この時もCMSという未知の領域への挑戦となり、色々と調査をしました。CMSでページを表示する仕組みはどうなっているか、どこがカスタマイズする部分なのか等々です。この時にインフラエンジニアとしての知識が役に立ったのかと言われると判断に困りますが、以下の原則を知っていたことはトラブルシューティングに大いに役立ったと思っています。

  • ハードディスクへのアクセスはメモリへのアクセスと比較すると遅い
  • ネットワークの通信は高速だが、コネクションの確立は遅い
  • データベースの処理は高速だが、トランザクションが増えると遅くなる

当時はこちらの原則を基にページごとのSQL発行回数を調査し、問題が発生しているページで1ページ表示ごとに2,000回ほどSQLを発行しているのを検知しました。これを解決するために、不要なSQL発行を減らそうとキャッシュ機構を利用し、メモリ上の情報でページを表示するように修正していきました。

これをきっかけにCMSを知っている人というレッテルを貼られることとなり、色々なCMS構築のプロジェクトに参加するようになりました。CMSという技術自体はなんて事のない、アプリケーションに寄った技術になりますが、これを運用・運営していくとなると考慮するべきことが大きく増えていきます。たとえば、コンテンツを配信する際のパフォーマンスと冗長性を上げるためにCDN(Content Delivery Network)を利用するであったり、コンテンツ編集画面を攻撃から防御するためのセキュリティであったり、WWWで公開するためのドメイン管理や証明書であったり、ログインを簡略化するためのSSO(Single Sign On)であったり、そもそも非機能要求に応えるための全体のアーキテクチャ検討であったり、です。

そんな中でも自分自身に良い経験となったのはCMSを利用したシステムの提案書を多く記述したことです。提案書を書くにはCMSを利用することで顧客の何が解決できるのか、何が楽になり、何が嬉しいのかを理解しておく必要があります。また同時にCMSの特性上、どのような要求には向いていないのかといったデメリットや弱点も理解しておく必要があります。こういった提案書を書くという行為から、CMSを使う側の視点で技術を分解できたと考えています。

新しい技術への向き合い方

2つのエピソードから共通点を振り返ってみますと、まず大きなポイントとなるのは新しい技術を利用する側の視点に立つことかと思います。アプリケーションエンジニアからクラウドエンジニアにシフトしていくときは、もともとクラウドを使いたいという立場でクラウド提供側の業務をしていたためクラウドに何があると嬉しいかといった視点で技術習得を進めることができたと思います。同様にCMSを学んでいく際も提案書執筆を通してこれがどのような価値があるのかという視点で考えていくことができました。

もう一つの共通点は、自らの意思でなく他者の意思によって決まっていったという点です。これは意外と重要な気づきで、ある一つの技術、分野を習熟していくとその分野に集中しがちで、未知の分野をやっていこうという気持ちが薄れていきます。未知に飛び込んでいくためにはパワーが必要で、そのパワーの出どころとして外圧というのは一つの選択肢になるのではないかと思います。もちろん、この「外圧が良かった」というのは結果論ですし、人によって受け入れやすい人と受け入れにくい人がいると思います。ただ、たとえ自分の意思ではなかったにせよ、未知の技術を習得する際に自らが持っている知識と未知の技術との関連付けをしながら学んでいくというのは効果がある手法だと思います。

次回からは具体的な例を通じて「インフラエンジニアが新しくアプリケーションのことを学ぶ」や、「アプリケーションエンジニアが新しくインフラのことを学ぶ」について見ていきたいと思います。

※本記事はエヌ・ティ・ティ・データ先端技術株式会社から提供を受けております。著作権は同社に帰属します。

[PR]提供：エヌ・ティ・ティ・データ先端技術