Google Cloud Platform Japan Blog
最新情報や使い方、チュートリアル、国内外の事例やイベントについてお伝えします。
航空券検索の大規模システムを Google Cloud Platform で構築した Amadeus
2016年1月6日水曜日
* この投稿は米国時間 1 月 5 日、Google Cloud Platform Team によって投稿されたもの（投稿はこちら）の抄訳です。 今回は、スペインに本拠を置く Amadeus のエアライン IT 担当 Senior Manager、Olivier Favorel 氏からお話を伺います。 図 1 ： Amadeus Airline Cloud Availability のアーキテクチャ 195 か国で事業を展開する Amadeus は、世界の旅行業界に IT ソリューションを提供する大手企業です。トランザクション当たりわずか 100 マイクロ秒の CPU 消費の増加が、1 年間で数千ドルのホスティング コスト増につながるような大規模ソリューションを手がけています。 このたび同社は、コストとパフォーマンスの管理を目的に Google Cloud Platform を導入しました。 航空券の平均検索数に対する予約の成約率（look-to-book レシオ）は、以前は 10 対 1 に達していました。それが今では 1000 対 1 まで落ち込むことも珍しくありません。 しかも、航空券の需要は決して一定ではありません。需要変動に対応するには、ピーク時の大量のトラフィックを予測し、必要なキャパシティ調整を行う必要があります。 これは航空会社にとって厄介な課題です。増加の一途をたどるオンライン購入トランザクションを処理するため、オンライン旅行サイトはキャッシュ ベースのソリューションを開発しました。 しかし、キャッシュ ベースのシステムには限界があります。航空会社の高度な売上管理ポリシーを正確に反映しないからです。 私たち Amadeus は、旅行の未来を形作る技術を開発しています。私たちのお客様とパートナーのビジネス ニーズを理解するため、航空会社に影響を与えるトレンドに非常に注目しています。そうしたトレンドの1 つが、さまざまなデジタル チャネルを通じて航空会社の商品をチェックして購入する消費者の急激な増加です。 大手航空会社は、旅行者から得られる価値を最大化して売り上げに結びつけることを目指しており、高度な売上管理ソリューションに投資しています。 売上高を最大化するには、すべての航空券検索をリアルタイムに処理し、特定の料金クラスの適切な空席を最適な価格で提供する必要があります。さらに、航空会社があらゆる販売機会を捉えるには、さまざまな購入プラットフォームにわたって一貫した形で空席を提供することが重要です。 ところが、キャッシュ ベースのシステムはリアルタイムの売上最大化と相反し、適切な商品を適切な顧客に適切なタイミングと価格で提供する航空会社のマーチャンダイジングとパーソナライズの妨げになります。 すべての流通チャネルにわたって適切で一貫した形で航空券の提供を続けるのは大変ですが、どうすればマスマーケット向けの動的コンテンツ配信で高いパフォーマンスを確保できるのでしょうか？ 私たち Amadeus は、Google Cloud Platform を利用してユニークなクラウド ベースのソリューションを開発しました。この Amadeus Airline Cloud Availability は、航空会社の予約システムから空席検索と購入トランザクションの処理を肩代わりします。また、それらの予約システムでは最終的な予約と決済が行われます。 このソリューションにより、どのようなパブリック クラウドにもプライベート クラウドにもデプロイできます。オンライン旅行代理店やメタ検索エンジン、グローバル流通システムで使用される購入プラットフォームに近い場所で、より効率の高いソリューションをフルに活用して航空券の提供が行われるようになります。結果的に、航空会社が検索および購入トラフィックの大幅な増加に効率的に対応するのに役立ちます。 私たちは 2015 年 2 月から 7 月まで、Lufthansa と共に GCP で Amadeus Airline Cloud Availability（プロジェクト コードネームは “R-Box” ）のパイロット運用を実施しました。その目的は下記の 2 つでした。 Google Compute Engine を使用した空席検索処理のスケーラビリティとパフォーマンスの実証。Amadeus は現在、ドイツのミュンヘンにあるプライベート データセンターで、140 社以上の航空会社のために空席検索を 1 秒当たり 400 万件以上処理しています。このトラフィックは毎年 50％ のペースで増えています。 空席検索および処理トラフィックのインフラストラクチャ コストの抑制 空席検索は、Couchbase クラスタでデータにアクセスする C++ バックエンド ファームで処理されます。分散 NoSQL ストアである Couchbase は、航空券のフライトと料金に関する詳細データをホストしています。 こうした大規模アプリケーションでは、CPU 消費が重要な指標になります。トランザクション当たりわずか 100 マイクロ秒の CPU 消費の増加が、1 年間で数千ドルのホスティング コストの上昇につながるからです。 私たちのソリューションの Compute Engine へのデプロイは、最初からシームレスに行うことができました。直感的なコンソールに加え、プリインストールされていた一連のさまざまな Linux イメージ（CentOS 7.1 を使用）のおかげです。 空席検索を処理するバックエンド インスタンスの最初に作成されたものは、初めてネットワークに接続されてからほんの 2 時間後に、トラフィックを受け入れる準備が整っていました。 1,500 コアのチャレンジ Amadeus と Google のエンジニアリング チームは、3 つのリージョン（米国中部、西欧、東アジア）に分散して割り当てられる 1,500 コアのキャパシティを最大限有効に活用するために協力しました。これらの各リージョンには、Couchbase のレプリケーション プロトコルである Cross-datacenter Replication（XDCR）を使用して航空券データが配布されています。 私たちのミッションは、1 ドル当たりの空席検索処理数を増やすことでした。そのためにいくつかの措置を講じました。 トランザクション当たりの CPU パス長の短縮。C++ の低レベルのいくつかの最適化を行い、Google のメモリ アロケータである TCMalloc を利用して短縮を実現しました。 アプリケーションのコアを稼働させ続けることを目的とした Couchbase データ ストアの IO スループットの向上。私たちは Compute Engine の内部ネットワークの安定性と非常に低いレイテンシに強い印象を受けました（Couchbase クラスタ ノードへのラウンド トリップがサブミリ秒で安定しています）。 Couchbase クラスタをホストする VM 上での NOOP スケジューラの有効化（SSD のスループットを高めるために最適な IO スケジューリング パターンを実現します）。 サーバーを常に 85～90％ の CPU 使用率で動作させるための VM サイズ（CPU /メモリの組み合わせ）の調整（アプリケーション サーバーには n1-highcpu-16 を、Couchbase クラスタ ノードには n1-highmem-4 を選択するなど）。 第 1 フェーズの変化 R-Box のパイロット運用の目標は当初計画よりもはるかに早く達成されました。GCP の柔軟性と Google のサポート チームのおかげです。 1,500 コアを使用した空席検索処理の全体的なスループットは、Amadeus と Google の協業開始からわずか 3 か月で倍増しました。 さらなる前進 私たちは現在、パイロット運用の第 2 フェーズに入っています。このフェーズでは以下のように、航空券需要の変動に応じたハードウェア キャパシティの動的な調整、VM のサイズの微調整、Compute Engine のプリエンプティブル VM（私たちがよく “低コストの VM ” と呼んでいるものです）の活用を目指しています。 動的なキャパシティ調整 Kubernetes（Google のコンテナ オーケストレーションおよびクラスタ管理ソリューション）を利用して実装が進められています。Kubernetes は、空席検索および処理トラフィックの変動に応じてアプリケーションの VM を動的に起動またはシャットダウンできるようにするために、R-Box フレームワークに導入されつつあります。 Kubernetes は、私たちの PaaS パートナーである Red Hat が、PaaS 製品およびサービスである OpenShift の一部として出荷しています（私たちは社内アプリケーション プラットフォームの Amadeus Cloud Services を、こうした戦略的製品上に構築しています。IaaS プロバイダーに対する独立性を確保するためです）。 さらに、インスタンスの料金が分単位の従量制であることも、ホスティング コストの最適化に役立ちます。 プリエンプティブル VM 2015 年 5 月にリリースされたプリエンプティブル VM は、通常の VM よりもはるかに低コストで（70％ 安く）利用できます。 ただし、Compute Engine が他のタスクのためにプリエンプティブル VM の使用するリソースにアクセスする必要がある場合、プリエンプティブル VM は、Compute Engine によってシャットダウンされる（プリエンプトされる）可能性があります。 私たちは、R-Box のコンピュテーション VM の数を 10％ 余分に設定し、これらをすべてプリエンプティブル インスタンスのみで賄うことを計画しています。これは、「こうした VM の一部が日常的にシャットダウンされてしまっても、全体的な処理能力は空席検索を処理するのに必要なレベルに保たれる」という想定に基づいています。 こうして新機能を活用することにより、大幅なコスト節減が見込まれます。 カスタム マシン タイプ 2015 年 11 月にリリースされたカスタム マシン タイプを、これまで使用してきた通常のインスタンス タイプ（n1-highcpu-16 と n1-highmem-4）の代替としてセットアップしています。 カスタム VM のサイズは、自社にとって必要最小限のコアとメモリ（GB 単位）で設定できます。カスタム マシン タイプの目的は、CPU とメモリの無駄をなくすことにあります。 Google Cloud Platform のインパクト Google Cloud Platform を利用した私たちのプロジェクトは非常にエキサイティングで印象深いものでした。その理由は以下のとおりです。 パフォーマンス ネットワークのレイテンシ、スループット、安定性は驚くべきものです。また、多くのリージョンで行われている VM の次世代 Intel アーキテクチャ（Haswell）への移行により、空席検索の処理パフォーマンスに CPU の大幅な性能向上の効果が現れるでしょう。 安定性 6 か月にわたるパイロット期間に VM が停止してしまうことはほとんどありませんでした。メンテナンスの通知プロセスも円滑に機能しています。VM のライブ マイグレーションは本当に透過的です。 モニタリング Stackdriver フレームワークでは、システムに関する指標（CPU、メモリ、IO）とユーザー定義の KPI（1 秒当たりの空席検索処理数に類似）の両方のリポート機能が優れています。効率的なアラート システムやモバイル アプリの「Cloud Console」との組み合わせにより、本番グレードのモニタリング ソリューションがたちまち出来上がりました。 イノベーションのペース 6 か月のパイロット期間中に、私たちのプロジェクトに役立つ大きな発表が 3 つありました。プリエンプティブル VM のリリース、カスタム マシン タイプの導入、そして最も重要な、2015 年 5 月に行われた 15％ の値下げです。 要約 Google Cloud Platform による R-Box のパイロット プロジェクトは、パフォーマンスの最適化に関する私たちのアプローチを変えました。私たちは CPU にどれだけコストをかけるかという観点を超えて、インフラストラクチャ全体で最適化を追求するようになったのです（最終的に重要なのは効率性です）。 Google Cloud Platform は、社内ベンチマーキングのための非常に効率的なサンドボックス環境です。Google Cloud Platform が今後、Amadeus の多くのアプリケーションにとって理にかなったホスティング ソリューションとなるのは間違いないでしょう。
月刊 Google Cloud Platform ニュース
2016年1月6日水曜日
Posted by 福田 潔 (Google Cloud Platform セールスエンジニア) 明けましておめでとうございます。本年も、Google Cloud Platform をどうぞよろしくお願いいたします。 早速ですが、先月（2015 年 12 月 ）発表された Google Cloud Platform 関連のニュースをブログ記事から振り返ってみます。 [新製品, 新機能] 待望のCloud SQLの新しい世代（第2世代）がベータリリースされています。Compute Engine ベースに生まれ変わり、従来版に存在していた性能面での制限事項が解消されました。 また、コストコントロール等管理系の機能を強化した BigQuery の新しいバージョンがリリースされました。 監査やコンプライアンスに役立つ Cloud Audit Logs 12/24 Google BigQuery - コスト計算と最適化 12/22 Google Cloud Shell の無料期間が 2016 年末まで延長に 12/21 BigQuery のカスタム クォータ機能や Query Explain をご紹介 12/17 次世代 Google Cloud SQL のベータが登場 12/13 使い勝手がよくなった Google Cloud Platform の新コンソール 12/10 Compute Engine リソース チェック機能を改善しました 12/09 画像認識の常識を変える Google Cloud Vision API 12/04 [顧客事例] 株式会社グラニの Google Cloud Platform 導入事例: 「using CSharp;」という軸と BigQuery の活用で、先進性を求め続ける。 12/2 [パートナー関連] クラウドのパフォーマンスを計測する PerfKit がバージョン 1.0 に 12/15 [Developer Tips] 2015年の大きなトピックとしてあげられるコンテナの広まりですが、Google Cloud Platform を利用すると、コンテナの実行環境となる Kubernetes クラスタの構築や コンテナ自体のログや監視機能を簡単に使うことができるようになっています。 Google Cloud Monitoring で Container Engine を監視しよう 12/22 Cloud Debugger：実際の運用環境でのトラブルシューティングを Python で 12/16 [ソリューション] AWS 経験者向けに書かれた Google Cloud Platform 入門のホワイトペーパーが公開されています。これにより、既にAWSを利用している方が Google Cloud Platform の世界に足を踏み入れることが容易になることを期待します。 金融データの変換という困難な課題への対処 12/28 新ホワイトペーパー公開 ： AWSプロフェッショナル向け、Google Cloud Platform 入門 12/24 Minecraft でコンテナ化にトライ 12/3 [その他] Google Cloud Platform のグローバル イベント Next を3月にサンフランシスコで開催することを発表し、申し込みの受付を開始しました。 GCP NEXT 2016 開催決定！ 12/21 2015年：クラウドの年 12/15
金融データの変換という困難な課題への対処
2016年1月6日水曜日
* この投稿は、米国時間 12 月 17 日、FIS の Principal である Salvatore Sferrazza と、FIS の Manager である Sebastian Just によって投稿されたもの（投稿はこちら）の抄訳です。 今回のゲスト投稿者は、投資情報サービスとテクノロジーソリューションの国際的なプロバイダである FIS Global 社のサルヴァトーレ・スフィラッツァ（Salvatore Sferrazza）、セバスチャン・ジャスト（Sebastian Just）の 両氏です。 断えず変動する大量の金融サービスのあらゆるデータを正確に取り込み、Google Cloud Dataflow でどのようにデータを変換し、システム間で転送できるようにしているのか、サルヴァトールとセバスチャンが教えてくれます。 投資市場向けの多くのソフトウェア（およびほとんどのエンタープライズ向けシステム）の開発で中心的課題となっているのは、システム間でのデータの変換、価値付加、転送です。 金融市場のデータ量は性質上、予測困難で、ボラティリティによる大きな影響を受けることも多いです。 そのため例えば、毎日のトレードの照合、決済、規制当局への報告書作成用のデータを、データ量に対応しながら必要なタイミングで必要な相手に知らせる仕事には頭を悩ませています。 このような重要な業務プロセスの中で技術的なミスが起きると、商機を逸したり法規制コンプライアンスに違反するなど、さまざまなリスクに不必要にさらされる可能性があります。 投資家の利益を最大化するためには、このような処理を、厳密な予測性、再現性の高さ、あるいは尺度により数値化することが求められます。 このようにデータの処理は極めて重要です。 開発企業はデータの抽出、変換、（ターゲットへの）ロード（ETL）処理を重要視しています。しかし処理可能な量が取引量の増大に追い付かず、ETL のスピードと効率上の限界に直面しています。 決済期間が短くなり総合監査証跡（CAT）が控えている中で、投資情報サービス機関は、データ量に合わせてスケーラブルに対応でき時間に大きく左右されるリスクと運用コストを低減できる、シンプルで高速で強力な手法を必要としています。 これまで開発企業は、データの抽出、変換、ロードを中心とした処理を、地味ではあるものの、ソフトウェア製品を作り上げる際にコンピュータ処理のあらゆる層の中核となる機能を組み込む上で欠かせない要素であると考えてきました。 このため、データ重視型の企業が膨大な数のデータ群から洞察を得る仕事をする際には、ほとんどの場合、何らかの形で ETL が関係しています。 その一方で、現代では、あらゆる分野であらゆる形のデータが発生するため、これらに対応することは、労力的にも、時間的にも、情報能力的にも困難になっています。 この問題にはさまざまな解決方法があるのでしょうが、現代の「ビッグデータ」の世界で要求される効率と効果を実現できる方法はほとんどありませんでした。少なくとも最近までは・・・。 Google Cloud Dataflow サービスと関連ソフトウェア開発キット（SDK）には、さまざまなデータ変換処理用の強力なツールが用意されています。 Google Cloud Dataflow は、マネージドサービス環境内であらゆる規模のデータ処理タスクを実行できるように設計されており、大量の変換処理に要求される機構を簡素化でき、同じプログラミングモデルでバッチ処理とストリーム処理のどちらにも対応できます。 私たちの最新の白書（英語）では、Dataflow でオプション市場の象徴的なデータを取り込み変換処理を行い、結果の Google BigQuery データセットへの保存処理をいつでも行うことのできるアプリケーションの構築と実行とその主要概念を紹介しています。 一言でいえば、Google Cloud Dataflow を使用することで、クラスタ管理に煩わされずにデータ処理の仕事に集中できるようになります。 適切なクラスタサイズの心配をしなくても、Dataflow が、自動的・水平的に、処理条件に合わせて正確にスケーラブルに対応してくれます。 このスケーラビリティ機能には、処理がないときにサイズを 0 に縮小する機能も含まれます。そのため、アイドリング中のクラスタのための費用が発生することはありません。またアプリケーションの実装に必要な作業も標準化されるため、ETL プログラムを作成する労力も軽減されます。 このため、処理機構自体に労力を掛けずに済み、必要なデータ変換作業のみに集中できます。これにより、抽出、変換、ロード作業の柔軟性を高め、時間を短縮し、管理を簡素化できるだけでなく、コスト管理機能を組み込んで効果的な他の Google Cloud サービスと連携させることもできます。 Dataflow パイプラインには、一般的な ETL 機能だけでなく、単純な計数機能からきわめて複雑な多段分析機能まで、さまざまな計算機能が組み込まれています。過去の経験を鑑みるとこのサービスにより、金融機関や監査機関のエンジニアの労力を大幅に軽減できるだけでなく、業務全体の柔軟性、正確性、スケーラビリティ、性能、コスト効率を高められる可能性があります。 マーケットのボラティリティや報告に関する要求に応えられる正確さ、高速応答、低リスクが要求される状況ではトレードの効率とアクセス性を確保が鍵になります。したがってビッグデータの世界でのマーケットデータの変換と解釈は欠かすことができず、一瞬もおろそかにすることはできません。 絶えず増加していくデータを、より高いコスト効率でリアルタイムにスケーラブルに処理できる方法があれば、金融機関は、条件やデータ量に応じた対応が可能になり、急速に進化しつつあるグローバル金融システムへの要求にも応えて行くことができます。 技術白書（英語）で発表させていただいた私たちの経験を、皆様のデータ処理の効率化にお役立ていただければ幸いです。 白書の GitHub のページでは、ビルド可能な完全なプロジェクトソースコードをご覧いただけます。 - Posted by Salvatore Sferrazza, Principal at FIS and Sebastian Just, Manager at FIS
Labels
Announcements
App Engine
AppScale
BigQuery
Billing Alerts
Case Study
Certification
Archive
2016
1月
Feed
Follow @GoogleCloud_jp
