Amazon Web Services ブログ

Category: AWS Lambda

Lambda Thumb

新機能 – Lambda関数の共有ファイルシステム – Amazon Elastic File System for AWS Lambda

本投稿は AWS の Chief Evangelist (EMEA)であるDanilo Pocciaによる寄稿です。 AWS Lambda関数がAmazon Elastic File System(EFS)をマウントできるようになったことを非常に嬉しく思います。EFSは、高可用性と耐久性のために複数のアベイラビリティーゾーン(AZ)にまたがってデータを格納するスケーラブルでエラスティックなNFSファイルシステムです。このように、使い慣れたファイルシステムインターフェイスを使用して、関数単体、および複数のLambda関数のすべての同時実行環境にわたってデータを保存および共有できます。 EFSは、強力な整合性やファイルロックなどの完全なファイルシステムアクセスセマンティクスをサポートしています。 Lambda関数を使用してEFSファイルシステムを接続するには、EFSアクセスポイントを使用します。これは、ファイルシステムへのアクセス時に使用するオペレーティングシステムのユーザーとグループを含むEFSファイルシステムへのアプリケーション固有のエントリポイント、ファイルシステムのアクセス許可、およびファイルシステム内の特定のパスへのアクセスを制限できます。これにより、ファイルシステム構成をアプリケーションコードから切り離しておくことができます。 同一のアクセスポイント、または異なるアクセスポイントを使用して、複数の関数から同じEFSファイルシステムにアクセスできます。たとえば、異なるEFSアクセスポイントを使用して、各Lambda関数はファイルシステムの異なるパスにアクセスしたり、異なるファイルシステムのアクセス許可を使用したりできます。 同じEFSをAmazon Elastic Compute Cloud(EC2)インスタンス、Amazon ECSとAWS Fargateを使用するコンテナ化されたアプリケーションや、オンプレミスサーバーと共有できます。このアプローチに従って、異なるコンピューティングアーキテクチャ(関数、コンテナ、仮想サーバー)を使用して同じファイルを処理できます。たとえば、イベントに反応するLambda関数は、コンテナで実行されているアプリケーションによって読み取られる構成ファイルを更新できます。または、Lambda関数を使用して、EC2で実行されているWebアプリケーションによってアップロードされたファイルを処理できます。 このようにすると、いくつかのユースケースではLambda関数によって実装がより容易になります。例えば: /tmpで使用可能な容量(512MB)より大きいデータを処理またはロードする。 頻繁に変更されるファイルの最新バージョンをロードする。 モデルやその他の依存関係をロードするためにストレージ容量を必要とするデータサイエンスパッケージを使用する。 呼び出し間で関数の状態を保存する(一意のファイル名またはファイルシステムロックを使用)。 大量の参照データへのアクセスを必要とするアプリケーションの構築。 レガシーアプリケーションをサーバーレスアーキテクチャに移行する。 ファイルシステムアクセス用に設計されたデータ集約型ワークロードとの相互作用。 ファイルを部分的に更新する(同時アクセス用のファイルシステムロックを使用)。 アトミック操作でファイルシステム内のディレクトリとそのすべてのコンテンツを移動する。 EFSの作成 EFSをマウントするには、Lambda関数がEFSマウントターゲットに到達できるAmazon Virtual Private Cloud(VPC)に接続されている必要があります。ここでは、簡単にするために、各AWSリージョンで自動的に作成されるデフォルトのVPC を使用しています。 Lambda関数をVPCに接続する構成にすると、ネットワーク環境の変化に伴う変更が必要になることがある点に注意してください。 Lambda関数がAmazon Simple Storage Service(S3)またはAmazon DynamoDBを使用している場合は、それらのサービスのゲートウェイVPCエンドポイントを作成する必要があります。 Lambda関数がパブリックインターネットにアクセスする必要がある場合、たとえば外部APIを呼び出す場合は、NATゲートウェイを構成する必要があります。通常、デフォルトVPCの構成は変更しません。特定の要件がある場合は、AWS Cloud Development Kitを使用してプライベートおよびパブリックサブネットで新しいVPCを作成するか、これらのAWS CloudFormationのサンプルテンプレートのいずれかを使用します。このようにすることで、ネットワークをコードとして管理できます。 EFSコンソールで、[Create file system]を選択し、default のVPCとそのサブネットが選択されていることを確認します。すべてのサブネットで、同じセキュリティグループを使用してVPC内の他のリソースへのネットワークアクセスを提供するデフォルトのセキュリティグループを使用します。 次のステップでは、ファイルシステムにNameタグを付け、他のすべてのオプションをデフォルト値のままにします。 次に、[Add access […]

Read More

Excel データを自動的に Amazon QuickSight に取り込む

Amazon QuickSight は、クラウドベースで高速なビジネスインテリジェンス (BI) サービスです。これにより、組織の誰もが容易に洞察を入手できるようになります。この投稿では、頻繁に変更されるデータを Amazon QuickSight ダッシュボードの SPICE (超高速、並列、インメモリ計算エンジン) データセットに自動でインポートする、サーバーレスのデータ取り込みパイプラインを構築する方法を示します。 BI 開発でアジャイルであることは、時には非常に困難です。たとえば、セルフサービス分析を実行するエンドユーザーは、追加のアドホックデータを既存のデータセットに追加し、対応する更新済みダッシュボードとレポートをタイムリーに表示することができます。ただし、ダッシュボードとレポートは通常、厳格なスキーマを持つ単一のオンライン分析処理 (OLAP) データウェアハウスの上に構築されます。そのため、エンドユーザー (データセットを直接更新する権限がない) は、ウェアハウスでデータを更新するために、複雑で時間のかかる手順を実行する必要があります。または、データセットを手動で編集するためにチケットを発行することもできますが、それでも非常に不便なソリューションであり、特にデータを頻繁に更新する必要がある場合は、相当な量の反復手動作業が必要になります。 したがって、リアルタイムのデータ取り込みを実行できる自動データ処理ツールは非常に便利です。この投稿では、エンドユーザーが Excel ファイルを Amazon S3 またはその他のデータファイル共有場所にアップロードするときに、次のエンドツーエンドプロセスを実行するツールについて説明します。 Excel ファイルから未加工データを消去します。これには、多くの書式設定と冗長な情報が含まれている場合があります。 クリーニングされたデータを取り込みます。 ステータスチェックを実行して、データのクリーニングと取り込みのプロセスをモニタリングします。 結果通知をエンドユーザーと BI 開発チームに送信します。 最近開始されたクロスデータソース結合機能により、ファイル間、ファイルとデータベース間、データベース間結合など、Amazon QuickSight がサポートするすべてのデータソース間で結合できます。詳細については、Amazon QuickSight のデータソース間での結合を参照してください。 クロスデータソース結合に加えて、Amazon QuickSight は SPICE 取り込み用の新しい API も開始しました。詳細については、データを SPICE にインポートと、Amazon QuickSight の新しい API とテーマ機能で、分析をさらに進化させるを参照してください。 この投稿では、これらの機能を組み合わせて、Excel ファイルをクリーニングして Amazon QuickSight の SPICE データセットに自動的に取り込むアジャイルソリューションを構築する方法を示します。SPICE […]

Read More

高速、低コストで、より良いAPIの構築 – HTTP APIが利用可能(GA)になりました

本投稿は、Senior Developer Advocate, AWS Serverless Applications のEric Johnsonの寄稿によるものです。 2015年7月、AWSはAmazon API Gatewayを発表しました。これにより、開発者はさまざまな種類のアーキテクチャのフロントに配置して安全でスケーラブルなAPIを迅速に構築できるようになりました。それ以来、API Gatewayチームは顧客向けの新しい機能とサービスを構築し続けています。 図1: API Gateway機能追加タイムライン 2019年初頭、チームは現在のサービスを評価し、API Gatewayの次の姿がどうあるべきか計画を立てました。新しい言語と技術によるプロトタイプを作成し、RESTおよびWebSocket APIの構築から学んだ教訓を適用し、そして、顧客のフィードバックを入念に調べました。その結果として、Amazon API GatewayのHTTP APIが完成しました。これは、より高速で、より低コストで使い易くなるように、ゼロから構築されたサービスです。要するに、HTTP APIはAPIを構築するためのより良いソリューションを提供します。APIを構築していて、HTTP APIが要件に合っている場合は、HTTP APIから始めるのが良いでしょう。   より速く ほとんどのユースケースで、HTTP APIはレイテンシを最大60%削減します。開発者は、最小限のレイテンシと最大限の機能を備えたアプリケーションの構築に苦心しており、アプリケーションプロセスに関係する各サービスがレイテンシを追加する可能性があることを理解しています。 図2: すべてのサービスがレイテンシを追加   これを念頭に置いて、HTTP APIは、API Gatewayサービスのレイテンシオーバーヘッドを削減するように構築されています。リクエストとレスポンスの両方を足し合わせても、すべてのリクエストの99%(p99)でHTTP APIからの追加レイテンシが10ミリ秒未満になります。   より低コストで Amazonでは、中核となるLeadership Principles の一つとして、Frugality(倹約)があります。私たちは、費用対効果の高い方法で物事を行い、その節約がお客様に還元されることを信じています。新しいテクノロジーが利用可能になり、ほぼ5年間にわたりAPI Gatewayを運用し得た専門知識により、より効率的に実行するためにHTTP APIを構築しました。 図3: REST / HTTP APIの価格比較 us-east-1の価格設定を使用して説明します。図3は、1か月あたりの1億回、5億回、および10億回のリクエストのコスト比較を示しています。全体的に、HTTP APIは、API Gateway REST APIと比較して少なくとも71%低コストです。   よりシンプルに HTTP […]

Read More

シーメンスが Amazon S3 データレイクの更新用に、フルマネージドのスケジューリングのしくみを構築した方法

シーメンスは 37 万人を超える従業員と 170 年の歴史を持つ、グローバルなテクノロジーをリードする企業です。シーメンスのネットワークとアセットを継続的に監視するシーメンスサイバーディフェンスセンター (CDC) が、同社をサイバー犯罪から保護しています。このときに生じる膨大なデータ負荷を処理するため、CDC は ARGOS と呼ばれる次世代の脅威検出と分析のためのプラットフォームを構築しました。ARGOS はハイブリッドクラウドソリューションで、フルマネージドの AWS のサービスを多用して、ストリーミング、ビッグデータ処理、機械学習を行います。 セキュリティアナリスト、データサイエンティスト、脅威インテリジェンスチーム、インシデントハンドラーなどのユーザーが、ARGOS プラットフォームのデータに継続的にアクセスします。さらに、さまざまな自動コンポーネントがデータを更新、拡張、削除し、情報の充実、データ品質の向上、PII 要件の実施を行ったり、スキーマの進化や追加データの正規化要件のためのデータ変更を行います。データを常に利用可能かつ一貫した状態に保つには、いくつかの課題があります。 このようなシナリオでは、オブジェクトベースのデータレイクは、従来のトランザクションデータベースと比較して、コストの観点では非常に有益ですが、アトミック更新をほとんど許可しない、あるいは極めて複雑でコストのかかる拡張を必要とします。この問題を解決するため、シーメンスは、クエリのパフォーマンスと可用性を損なうことなく、 Amazon S3 ベースのデータレイクでアトミックファイルを更新できるソリューションを設計しました。 この投稿では、S3 データ更新タスク用の使いやすいスケジューリングサービスであるこのソリューションをご紹介します。仮名化、匿名化、機密データの削除など、いくつかの目的のために、シーメンスはこのソリューションを使用しています。この投稿では、このソリューションを使用して、定義した時間が経過した後にデータセットから値を削除する方法を説明します。ソリューションのアーキテクチャは明確に定義されており、スタック全体が 200 行未満のソースコードで構成されているので、データ処理タスクをさらに追加することは難しくはありません。フルマネージドの AWS サービスだけをベースにしているため、運用オーバーヘッドが最小限に抑えられます。 アーキテクチャの概要 この投稿では、クエリメカニズムとしての継続的なデータ取り込みと Amazon Athena を備えた S3 ベースのデータレイクを使用します。取り込み後、定義した時間後の特定の値を自動的に削除することを目指します。Athena を介してデータを使用するアプリケーションとユーザーは、影響を受けません (たとえば、ダウンタイムや重複などのデータ品質に関する問題はありません)。 次の図は、このソリューションのアーキテクチャを示しています。 シーメンスは、以下のサービスとコンポーネントでソリューションを構築しました。 スケジューリングトリガー – 新しいデータ (JSON 形式など) を S3 バケットに継続的にアップロードします。 タスクスケジューリング – 新しいファイルが到着するとすぐに、AWS Lambda 関数が結果の S3 バケット通知イベントを処理します。処理の一部として、Amazon DynamoDB に Time […]

Read More

Amazon EventBridge パートナーとしての日本の SaaS ベンダーのご紹介

Amazon EventBridge をご存知でしょうか? EventBridge は、独自のアプリケーション、SaaS および AWSのサービスから発行されるイベントをタイムリーにトリガーできるようにするサーバーレスなイベントバス機能として 2019年に発表されました。CloudWatch Events の拡張として作られており、AWSサービスからのシステムイベントも受信できますが、一番の特徴は、サードパーティの SaaS からイベント発行していただけるような仕様になっていることです(こちらもご覧ください)。 上図の左下あたりにある [SaaS Apps] として対応いただいたアプリケーションをご利用いただくと、SaaS 側で発生したイベントを SaaS 利用ユーザー側の AWS アカウント(SaaS アプリケーションとは異なる環境)へ EventBridge を経由してイベント通知することができるようになります。これによって、利用ユーザー環境で AWS Lambda の関数で追加の処理を起動したり、Kinesis/SQS/SNS にメッセージを飛ばしたり、Step Functions のフローを起動するなどの Push 型処理を簡単に実現できるようになります。つまり、SaaS がサーバーレスアプリケーションのトリガーとしてサーバーレス環境と融合することになるのです。 直近で BlackBelt セミナーも実施しましたので、EventBridge というサービス自体を理解したい方はこちらをぜひご覧ください。

Read More

Amazon DynamoDB、AWS Lambda、および Go を使用してエンタープライズアプリケーションを構築する

Amazon DynamoDB は、あらゆる規模で 1 桁のミリ秒のパフォーマンスを提供する、完全マネージド型サービスです。完全マネージド型で、舞台裏のマルチ AZ データレプリケーションを通じて高可用性を実現し、Amazon DynamoDB Accelerator (DAX) および複数のグローバルセカンダリインデックスを使用したネイティブライトスルーキャッシングをサポートします。開発者は、この投稿の焦点である Go を含む豊富なプログラミング言語のセットで AWS SDK を使用し、DynamoDB と対話できます。 この投稿では、CRUD を集中的に使用するアプリケーションに対して固有の使用例と、DynamoDB、AWS Lambda、Go を使用してそれらを効率的に処理する方法について説明します。CRUD は、作成、読み取り、更新、削除を表します (Wikipedia の作成、読み取り、更新、削除を参照してください)。この用語は、多数の異種オブジェクトを管理するアプリケーション、複雑なビジネスモデル、高度な自動化を伴う業界で一般的に使用されます。この投稿では、ホスピタリティ業界の例を使用していますが、基本的な設計原則はさまざまなエンタープライズアプリケーションに適用されます。 この投稿は、DynamoDB と Go を使用してエンタープライズアプリケーションを設計および構築するための、優れたプラクティスと例を探しているソフトウェアエンジニアを対象としています。詳細については、GitHub リポジトリを参照してください。GitHub リポジトリのコードは、本番稼働での使用が推奨されないクイックプロトタイピング用に作成されています。 前提条件 このチュートリアルを完了するには、AWS CLI アクセス権を持つ AWS アカウントを持ち、AWS CDK をインストールする必要があります。詳細については、AWS CDK の使用開始を参照してください。API Gateway エンドポイントと Lambda 関数の構築については、GitHub リポジトリを参照してください。 ユースケースとアプリケーション設計 最新のホテルの中央予約システムにより、ホテルチェーンと独立したプロパティは、コンテンツ (写真、動画、部屋の説明、部屋と料金、流通ルールなど) を管理し、さまざまな流通チャネル (オンライン旅行代理店、チェーンウェブサイト、内部予約エンジンなど) を通じて商品を検索し、予約できるようにします。これらの特殊なアプリケーションは、ホテルのフロントデスクのエージェントから最終ゲストまで、チェーン企業の従業員など、何百ものユースケースを多数のユーザーに公開します。これらのユースケースは、一般的に次のファミリーに適合します。 管理ユースケース – 通常、ホテル経営者やオフィスの従業員は、それぞれが相互に依存する多数の属性で構成される CHAIN、BRAND、PROPERTY、ROOM、ROOM_TYPE、PRICING_RULE […]

Read More

モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました

皆さん、こんにちは! モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー(日本語版)がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS(英語版)の日本語版になります。   ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」(日本語版)というタイトルの51ページのドキュメントで、 はじめに モダンアプリケーション開発 モダンアプリケーションの設計パターン AWSでのCI/CD まとめ の各章から構成されています。各章の簡単なご紹介は下記の通りです。

Read More

ECS、S3、Athena、Lambda、AWS Data Exchange を使用して、詳細な暗号通貨市場データを収集して配布する

これは Floating Point Group によるゲスト投稿です。彼らの言葉を借りると、「Floating Point Group は、機関投資家レベルの取引サービスを暗号通貨の世界にもたらすことをその使命としています」。 デジタル資産の取引向けに設計された金融インフラの必要性と需要はどれだけあるのかは、はっきりしないかもしれません。コインとトークンは、通貨、商品、株式、債券などの従来の資産に効果的にネイティブに相対するデジタル商品であると、広く受け止められています。この説明はよく、専門家が仮想空間内のさまざまなプロジェクトの価値提案を伝えようとするときに、力強く簡潔に伝えるために繰り返し用いられています (「ビットコインは、アルゴリズムで制御された改ざん防止の財務ポリシーが備わった、単なる通貨です」、または、「イーサリアムは、ガソリンのような金融商品です。それを使って、グローバルコンピューターの計算作業に支払うことができます」)。驚くことではありませんが、FPG である質問をよく耳にします。「暗号通貨が専用の金融サービスであることを保証するのに特別な点は何かありますか? なぜすでに解決された問題の解決策が必要なのですか」 実際、これらの資産とそれを取り巻く広範な公共の利益には、まったく前例がありません。ネットワークトランザクションのイミュータブルな記録として機能する分散型台帳テクノロジー。合理的なアクターを経済的に動機付けてネットワークのセキュリティを維持するためのプルーフオブワークアルゴリズムの巧妙な使用 (プルーフオブワークの概念は少なくとも 1993 年まで遡りますが、このテクノロジーが広く採用される可能性が示されたのは、ビットコインが登場してからです)。人的ミスや強要などの場合に固有の法的課題を引き起こす不可逆的な取引の性質。自己管理の不安定性 (サードパーティの保管ソリューションには、信頼を高める実績はありません)。これらの資産を分類することと、最終的に IRS、SEC、CFTC のようなエンティティによって調整する必要がある通貨交換を仲裁することの両方の困難を伴う規制上の不確実性。これらはすべて、非常に新しく、非常に特異なものです。24 時間取引が行える市場の規模は定期的に 1,000 億 USD を超えており、この記事では特にこれらの資産の取引に関連する問題に焦点を当てます。 確かに、仮想通貨取引は、ウェブフォーラムでビットコインを交換し始め、国際取引所間で 10% の価格スプレッドが確認されて以来、間違いなく成熟してきました。しかし、まだ長い道のりがあります。 機関投資家のために取り組むことを目指す上で抱える主な問題点の 1 つに、流動性 (またはより正確には、流動性の欠如) の問題があります。簡単に言えば、暗号通貨の売買は多くの異なる取引の場 (取引所) で行われ、流動性 (特定の価格で特定の量の資産を売買するオファー) は、新しい取引所が出現するにつれて断片化し続けています。100 ビットコインを購入しようとしているとしましょう。あなたは売りたい人から買う必要があります。最良の (最も安い) オファーを取得するにつれ、残りのオファーはどんどん高価になります。注文を完了するまでに (この例では、100 ビットコインをすべて購入するまでに)、たとえば注文の最初のビットコインに支払った価格よりも平均的にはるかに高い価格を支払うことになったかもしれません。この現象はスリッページと呼ばれています。スリッページを最小限に抑える 1 つの簡単な方法は、オファーの検索範囲を広げることです。そのため、1 つの取引所のオファーを見るのではなく、数百の取引所のオファーを見るのです。このプロセスは、従来スマートオーダールーティング (SOR) と呼ばれ、当社が提供するコアサービスの 1 つです。当社の SOR サービスにより、トレーダーは数十の取引所の流動性を積極的に監視することで、システムが複数の取引所で利用できる最高のオファーとマッチする注文を簡単に送信できます。 最良の価格を求めて大量注文を出すことは、かなり直感的で広く適用できる概念です。株式の約 75% が SOR を介して売買されています。けれども、暗号化市場向けのこのようなサービスの価値は特に顕著です。既存の取引所が行き詰まる中、新しい取引所が人気を博すという永続的なサイクルのため、取引所全体で流動性が絶え間なく断片化されています。けれどもトレーダーは、取引所に依存しない考え方を持つ傾向があります。ある特定量の資産にとって最良の価格を見つけることにのみ関心があるのです。 […]

Read More

Kinesis と DynamoDB をイベントソースにする際の AWS Lambda の新しいスケーリング管理

AWS Lambda は、Amazon Kinesis Data Streams と Amazon DynamoDB ストリームのイベントソースで利用可能な、新しいスケーリングパラメータを導入しました。Parallelization Factor は、各シャードにおける Lambda 関数呼び出しの同時実行数を増やす設定を可能にします。このパラメータは、デフォルトでは 1 です。これによって、処理されるレコードの順序を保証しながら、シャード数を過大にスケールすることなく、より高速なストリーム処理が可能になります。

Read More

【開催報告】ビルシリーズ@住友不動産六本木グランドタワー 第1回

みなさんこんにちは!アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクトの木村公哉です。 11月21日に「ビルシリーズ@六本木一丁目住友不動産六本木グランドタワー 第1回」を開催いたしました。今回は「初めてのサーバレスWebアプリケーションハンズオン」を実施しました。こちら「ビルシリーズとは?」とお思いの方も多いかと思いますので、開催報告と合わせてご説明いたします。 「ビルシリーズ」とは? このイベントは、日頃AWSをご利用いただいているお客様に、AWSからの情報発信はもちろん、同じビルに拠点を構えるお客様同士の活発な意見交換と交流の場を定期的に作ることを目的としたものです(同じビルなので移動が楽!)。 今回、住友不動産六本木グランドタワーのFringe81様、BASE様、エブリー様、ディップ様で同じようなニーズがあり、このようなビル単位でのイベントを開催する運びとなりました。場所はFringe81様の素敵な大会場をお借りいたしました。Fringe81様ありがとうございました。 来月には住友不動産麻布十番ビルでも開催を予定しており、今後もこのようなビル単位で交流ができるようなイベントを開催していきたいと考えております。 当日の様子 当日は約40人のお客様にお越しいただき、イベントは終始盛り上がりを見せておりました。   まずはAWSJ 植本より、今回のビルシリーズの趣旨などを説明いたしました。   次に、AWSJ 木村より「サーバレスのご紹介 – ユースケースパターンを切り口に」というタイトルで、AWSのサーバレスプラットフォームについてご紹介いたしました。   続けてAWSJ 木村より「初めてのWebアプリケーションハンズオン」を実施いたしました。   ハンズオンの終了後、ご参加いただいた皆様と共に、簡単な懇親会を開催いたしました。   今回、AWSJより、アカウントマネージャー植本、藤田、細木、ソリューションアーキテクト上原、石見、小宮、木村がビルシリーズをサポートいたしました。こちらはソリューションアーキテクトの集合写真です。 貴社担当のアカウントマネージャから「ビルシリーズ」のお誘いがあるかもしれませんが、是非ご検討いただければと思います。それでは、次回のビルシリーズでお会いしましょう!   著者について 木村 公哉(Kimura, Koya) 香川県出身のソリューションアーキテクトです。好きなサービスはAWS AmplifyとAWS Lambda、Amazon Kinesisです。好きな食べ物はうどんです。   上原 誠(Uehara, Makoto) アマゾンウェブサービスジャパン株式会社のソリューションアーキテクトとして、主にメディア系のお客様に対する技術支援を担当。技術的な得意/興味領域としては、アナリティクス系テクノロジー、広告系ソリューションなど。

Read More