Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
Google エンジニアが語る App Engine のインパクト
2016年5月12日木曜日
* この投稿は米国時間 4 月 26 日、Technical Support の Director である Luke Stone によって投稿されたもの（
投稿はこちら
）の抄訳です。
2011 年 12 月、Google 在籍 9 年目だった私は、ソフトウェア開発者 10 人のチームを率いて AdSense 事業をサポートしていました。私たちは 30 以上のソフトウェア システムを担当し、その大部分は、それまでの 10 年間に構築されたビジネス インテリジェンスのウェブ アプリケーションでした。
これらはいずれもその都度、良かれと思われたスタック上に構築されていました。その一部は、Google の（当時）最新のウェブ サーバー ライブラリをベースとし、Borg（Google の柔軟なクラスタ管理技術）上で直接動作する最先端のカスタム サーバーでした。
また、マネージド ホスティング サービス上の LAMP スタックもありました。なかには、誰かのワークステーションで cron ジョブとして実行されていたものもあります。
さらに、一部は奇妙で複雑なものになっていました。Borg 上で LAMP スタックが動作し、Apache が本番ロード バランサおよび暗号化システムと連携するようにカスタマイズされているといった具合です。
かくして、毎日のように新しい妙なトラブルが発生していました。どうにかシステムを動かし続けるのがやっとというのが、当時の私たちの状況でした。
チームにはストレスがたまっていました。プロダクト マネジャーもエンジニアも不満を抱えていたのです。こんな会話が日常茶飯事でした。
プロダクト マネジャー :
機能 A を追加するのは簡単という話だったけど、もう 4 日たっているよ。
エンジニア :
わかってます。でも、まずパッケージ マネージャをアップグレードしたうえで、古くなった API から移行しなければならなかったんです。その作業はほぼ終わっています。私も機能 A に取りかかりたいんです。
プロダクト マネジャー :
そうか。まだこれからか。
私はチームを調査し、私たちの効率が悪い根本原因を探りました。すると、業務時間の 60 % をメンテナンスに費やしていることが判明しました。この割合はどのくらいが適当なのか意見を募ったところ、しぶしぶながらも 25 % ならば許容範囲という結論に落ち着きました。
そこで私たちは、メンテナンスにかける時間の割合をそこまで減らすという目標を立てました。これが実現すれば、10 人の開発者のうち 3.5 人分の時間をメンテナンス以外の仕事に回せる計算でした。
Google App Engine
が 2011 年 9 月に正式なサービスとしてリリースされて間もないころ、これを熱心に薦めてくれた友人がいました（彼は個人サイトで使っていました）。メンテナンスの負担が少なく、スケーリングが自動的に実行され、Google Cloud Datastore やユーザー管理といった機能がビルトインされていると、べた褒めでした。
同じく友人の Alex Martelli も、いくつかの個人プロジェクトで
Google App Engine
を使っていました。私自身も 2010 年からユーザーでした。チャリティ ウェブ サイトで使っていたのです。
こうしたことから、私たちはチームのウェブ運用のために
Google App Engine
を全面的に採用することを決断しました。チームにとって PaaS への第一歩でした。
そのころ、私たちは Dremel（BigQuery の社内版）も使い始めました。Dremel は MapReduce と比べて格段に高速で、スケーラビリティもほぼ互角でした。私たちはすべてのデータ処理のコードを、Dremel を使用するように書き換えることを決めました。
ただし当時は、Dremel と App Engine を組み合わせて使う場合、足りない機能がいくつかありました。可視化やデータ パイプラインといったものです。
そこで私たちは早急にソリューションを開発しましたが、それらは Google の数百のプロジェクトでいまだに使われています。今では Google Cloud Platform のユーザーも、Google Cloud Datalab でそれらに似た機能にアクセスできるようになっています。
続いて私たちは、ソフトウェア開発者の仕事のあり方が一変するのを目の当たりにしました。確かに、30 のシステムを書き換えなければなりませんでしたが、それらはどのみち書き換える必要がありました。
書き換えを経て始まったクラウドでの開発は、極めて迅速に進みました。App Engine のログを見て驚いたことを思い出します。私は 1 回のコーディング セッションで、コード作成、テスト、デプロイのサイクルを 100 回もこなしていたのです。システムはいったん動き出すと、ずっと稼働し続けました。
私たちは次のプロジェクトにどのスタックを採用するかを議論しなくなりました。Google Cloud Platform で自明な選択肢を選んで、構築を始めるようになったからです。私たちがクラウド インフラストラクチャでバグを見つけると、専門家がすぐに修正してくれました。ライブラリの互換性のトラブルシューティングに何時間も費やしていたのとは大違いです。
App Engine を導入して何よりも良かったのは、メンテナンスにかかる時間の割合をたちまち 25 % に削減でき、さらに減らし続けることができたことです。導入 2 年後に再調査したところ、チームがメンテナンスに費やす時間の割合はわずか 5 % となったことがわかりました。
おかげで、別の前向きな課題に取り組めるようになりました。私たちは、ビジネス部門がアイデアを生み出すペースに対応してなお余力があり、バックログ（未処理案件）もなくなったからです。
そこで四半期末ごとに 2 週間をかけて “ハッカソン” を開催し、自分たちにできることの模索を始めました。開発者の半数をクラウド以外の忙しいチームに送り込んだほか、大きなプロジェクトに挑戦し、もっと大規模な開発チームを上回るペースで成果が出るようになりました。
PaaS の導入が私たちのチームにもたらした変化に鑑み、私はあらゆる人に PaaS を経験してほしいと考えています。ありがたいことに、この技術は Google のエンジニアだけでなく、世界中の開発者が利用できます。
これは、私が 1999 年に Google 検索に初めて触れて以来見てきた中で、最もインパクトが大きい技術です。この技術を活用すれば、開発者は無味乾燥な作業をやめて、私たちの生活に価値をもたらすアプリケーションの開発に力を注ぐことができるのです。
- Posted by Luke Stone, Director of Technical Support
0 件のコメント :
コメントを投稿
Labels
App Engine
AppScale
BigQuery
Billing Alerts
Cloud Bigtable
Cloud Consoleアプリ
Cloud Dataproc
Cloud Debugger
Cloud monitoring
cloud Pub/Sub
Cloud SQL
Cloud Storage
Compute Engine
Compute user Accounts
Container Engine
Container Registry
Deployment Manager
Developers
Firebase
Google Cloud Console
Google Cloud Dataflow
Google Cloud Datalab
Google Cloud Datastore
Google Cloud Launcher
Google Cloud Logging
Google Cloud Security Scanner
Google Cloud Shell
Google Cloud Storage Nearline
Google Genomics
IoT
Kubernetes
MySQL
Next
OLDISM
Panda
Puppet
Startups
Vision API
Vitess
イベント
コンピューティング
サポート
スタートガイド
ストレージ
セミナー
ソリューション: メディア
データセンター
ビッグデータ
運用管理
機械学習
月刊ニュース
資格、認定
新機能、アップデート
導入事例
料金
Archive
2016
5
4
3
2
1
2015
12
11
10
9
8
7
6
5
4
3
2
1
2014
12
11
10
9
8
6
5
4
3
2
Feed
Follow @GoogleCloud_jp
0 件のコメント :
コメントを投稿