mixi engineer blog

＊＊＊ 引っ越しました。最新の情報はこちら → https://medium.com/mixi-developers ＊＊＊ ミクシィ・グループで、実際に開発に携わっているエンジニア達が執筆している公式ブログです。様々なサービスの開発や運用を行っていく際に得た技術情報から採用情報まで、有益な情報を幅広く取り扱っています。

【CREウィーク木曜日】ChatOpsによる解析基盤の運用改善とAWSクロスアカウント環境におけるChatbotの実装例

※こちらの記事は過去のブログから転載したものです。

こんにちは。XFLAG スタジオ CREチームの田村です｡

 

XFLAG スタジオには、CREチームがユーザーさんからの問い合わせに基づいてサーバのログ調査を行なったり、プロダクトの様々なデータを集計したりするためのデータ解析基盤があります。今回、私はこの解析基盤の運用コストを削減するため、Slack Chatbotに運用をサポートする機能を実装しました。そこで本エントリーでは、CREチームで導入しているChatOpsの実例と、その実装の過程で行ったクロスアカウントと呼ばれる環境におけるリソース操作の方法について紹介したいと思います。

 

背景

XFLAG スタジオでは、モンスターストライクをはじめとする複数のプロダクトを抱えています。それぞれのプロダクトで利用しているAWS環境は用途別にアカウントを分離しており、チームが必要以上の権限と責任を持つことがないようIAMによってユーザーやロールを作成し、権限を管理しています。

 

CREチームもサーバのログ調査に用いる解析基盤や業務自動化ツールの運用基盤にAWSを利用しています。ログ調査には主にElasticMapReduce (以下、EMR)を使用しますが、EC2などに比べてEMRは時間あたりのコストが高くつくため、調査を始める際にEMRクラスタを立ち上げ、調査が終了するとクラスタを破棄する、という運用方法をとってきました。

 

しかし、この運用にはいくつかの問題がありました。それは次のようなものです。

  1. EMRは時間に対する従量課金制であるため、クラスタを破棄し忘れると処理を行なっていなくても時間分の料金が発生する
  2. 連続して他のメンバーが使いたい場合でも、一度クラスタを破棄してしまうとまた立ち上げなおす必要があった (EMRクラスタの起動はプロビジョニングが走るように設定されているため、調査の開始まで時間がかかってしまう)
  3. (2)を回避するため「次誰か使いますか？使わないなら落とします」というコミュニケーションが発生していた

f:id:mixi_PR:20210219125816p:plain

図1 EMR使用状況を確認するコミュニケーション


対策

これらの問題を解決するために、CREで運用しているSlack Chatbotから他のチームメンバーのEMR利用状況を確認できるようにし、一定時間使用していない場合は自動的にクラスタを終了するという方法をとることにしました。

 

機能の実装にあたって、まずは新しいEMRの運用方法を決めました。

- SlackでChatbotに対してEMRクラスタを使用することを宣言し、ロックをかける - EMRクラスタを使い終わったら、ロックを解除する

- 一定時間内に他のメンバーがロックを取得した場合にはEMRクラスタは残す

- ロックが解除された状態で一定時間経過すると自動的にEMRクラスタを破棄する

 

この運用変更によって、従来はチームメンバーが各自でとっていたコミュニケーションをChatbotが仲介します。

クロスアカウント環境による弊害

EMRクラスタの操作にはAWS APIが利用できます。そのため、私は実装開始当初はSlackで送信したメッセージに応じてAPIリクエストを飛ばす簡易な実装で済むと考えていました。

 

ところが、いざ実装という段になって環境に起因する問題が発覚しました。それは、解析基盤とChatbotの動作環境が図2のように別のAWSアカウント上に存在していたことです。

 

f:id:mixi_PR:20210219125052p:plain

図2 業務効率化基盤と解析基盤のインフラ構成

　このようにAWSアカウントをまたぐリソース同士の関係性をクロスアカウントと呼びます。当然ながらクロスアカウントではそれぞれのアカウントで作成されたIAMのユーザーやロールは共有されず、本来ならば別のアカウント内のリソースにアクセスすることはできません。

しかし、AWSにはこのような要求に応えるための仕組みが用意されています。クロスアカウント環境において別のアカウント上にあるリソースを操作するためには、はじめに対象のアカウント同士で信頼関係を確立する必要があります。この設定を行うことができるのはAWSアカウントの管理者ユーザーのみです。

 

今回の事例では、まず以下のように必要なIAMユーザーとロール、及びポリシーを準備しました。

f:id:mixi_PR:20210219124550p:plain

図3 クロスアカウントでリソースを操作するためのIAM設定

 

  • アカウントAにはChatbotで使用するためのAWSユーザー (user/cre) を作成
  • アカウントBにはEMRを操作するためのロール (role/cre) を作成

 

AssumeRoleポリシーはアカウントAのユーザーがアカウントBのAssumeRole APIに対するアクセス権限を得るために必要です。したがって、アカウントAのIAMに作成するAssumeRoleポリシーの `Statement.Resource` フィールドには、アカウントBのIAMロールを指定しなければなりません。

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::<アカウントBのAWSアカウントID>:role/cre"
  }
}

加えて、アカウントBではEMRクラスタに関するポリシーを作成します。今回はChatbotからEMRクラスタの一覧取得と破棄を行うため、 `Statement.Action` フィールドに `elasticmapreduce:ListClusters` と `elasticmapreduce:TerminateJobFlows` を追加しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticmapreduce:ListClusters",
                "elasticmapreduce:TerminateJobFlows"
            ],
            "Resource": "*"
        }
    ]
}

　次に、これらのIAMの設定を利用して別のAWSアカウント上のリソースを操作するまでのフローについて説明します。図4は、アカウントAのEC2インスタンスからアカウントBのEMRクラスタを終了するAPIリクエストを完了するまでの流れです。

f:id:mixi_PR:20210219124718p:plain

図4 クロスアカウント環境におけるAPIアクセスフロー

　まず、アカウントAからアカウントBのAssumeRole APIに `user/cre` ユーザーのトークンをPOSTし、`role/cre` ロールがアタッチされたトークンを取得します。ここで取得したトークンをアカウントBのEMR APIのエンドポイントにPOSTすることで、以降EMRの操作を行うことができます。

 

ここで注意するべきは、`role/cre` ロールは `user/cre` ユーザーにアタッチされるわけではなく、取得したトークンに紐づいているということです。そして、このトークンには有効期限が存在します。したがって、有効期限をすぎて失効すると再びトークンを取得し直さない限り、アカウントAからアカウントBのリソースにはアクセスできなくなります。

Slack Chatbotへの機能実装

CREチームがSlack Chatbotの開発に使用しているフレームワークは [slack-ruby/slack-ruby-bot](https://github.com/slack-ruby/slack-ruby-bot) です。ここまで説明したフローを踏まえて、Chatbotにトークン取得処理の実装を行うと次のようなフローになります。

f:id:mixi_PR:20210219124810p:plain

図5 ChatbotのEMR操作実行フロー
  • SlackからEMR操作用のメッセージを送る
  • AssumeRole APIからアカウントBの `role/cre` トークンを取得しデータベースにトークンの文字列と有効期限を保存する
  • 有効期限が切れるまでに受信したEMRコマンドには同じトークンを使い回す
  • 有効期限が切れていたら再度トークンを取得し直し、データベースを更新する

 

この流れに沿ってRubyで次のような実装を行いました。クライアントライブラリには AWS SDK for Rubyを使用しています。

class EmrClient
    def self.find_or_update_role_credentials
        # トークンの有効期限が過ぎている場合はAssumeRole APIから再度取得
        if current_credentials.expired?
            new_credentials = productivity_env_client.assume_role(
                # role/creロールのARN
                role_arn: "arn:aws:iam::123456789012:role/cre"
            ).credentials

            # 新しいトークンをデータベースに保存
            save_credentials(new_credentials)

        # 有効期限内はトークンを使い回す
        else
            current_credentials
        end
    end
end

　Slack Chatbotの機能一覧を示します。時間指定で実行する機能に関してはCRONを使用しています。

表1 Slack ChatbotのEMR操作機能一覧
Slackメッセージ 機能説明
emr status EMRの起動状態および使用中かどうかの確認
emr lock EMRクラスタの使用権を取得する
emr unlock EMRクラスタの使用権を解放する
emr terminate EMRクラスタを破棄する
- ロックされていない状態で30分たつと自動的にEMRクラスタを破棄する
- 終業時間 (19時) ぴったりにEMRクラスタを破棄する

 

この実装をChatbotに対して行い、ChatOpsによるEMRクラスタの運用を開始しました。

 

結果

従来は、EMRクラスタを使いたい場合、まずクラスタが立ち上がっていることを確認し、図1で示したように誰か他のメンバーが使用していないか確認するために全体にメンションする必要がありました。

 

それに対して、Chatbot導入後は作業中の他メンバーのアテンションを奪うようなコミュニケーションが発生することがなくなりました。相手がボットであればメンションを飛ばすことを躊躇う必要はなく、気軽にEMRクラスタの利用状況を確認することができます。 　

 

こちらが実際に、Chatbotを利用してEMRクラスタの運用を行なっている様子です。

f:id:mixi_PR:20210219125908p:plain

図6 Chatbot導入後のEMRの運用


さいごに

ChatOpsは自動化によるコスト削減やオペレーションの可視化などが注目されてきました。しかし、今回導入した機能に関して言えばチームメンバーの心理的な負荷を軽減する役割の方が大きかったように思います。

「EMR使ってますか。落としていいですか」というコミュニケーションは業務の本質的な部分ではなく、定常的にそのような状況が発生することはチーム全体の集中力を削ぐことにも繋がるため望ましくありません。もし、みなさんの日常業務でも同じような場面があれば、ChatOpsの導入を検討してみてはいかがでしょうか。
 

以上、ChatOpsによる解析基盤の運用改善と、その過程でクロスアカウント環境でのAPIアクセスを実装したお話でした。

さて、CREウィーク最終日の明日は神が「CRE チームで活きたこれまでの経験」について書きます。
お楽しみに！

- 参照資料 -

docs.aws.amazon.com

aws.amazon.com

 

 

【CREウィーク水曜日】サブスクリプションのちょっと危険でディープなお話

※こちらの記事は過去のブログから転載したものです。

こんにちは。XFLAG スタジオ CRE チームの上埜です。

 

XFLAG スタジオでは、スマホアプリ「モンスターストライク」(以下モンスト)内で「モンパス」という月額課金制の会員サービスを昨年2017年9月13日より開始しました。
モンパスは App Store, Google Play Store, Amazon Appstore の3つのプラットフォームで提供しており、会員サービスの購入・継続の処理はそれぞれのプラットフォームのサブスクリプション機能を利用して実装しています。

 

この記事では、プラットフォーム側から提供される契約情報が当初の想定と異なっており困ったケースがありましたので紹介したいと思います。

モンパスについて

モンパスの購入・継続の仕組み

モンパスの購入・継続時の実装について簡単に説明します。

f:id:mixi_PR:20210129155653p:plain
図1 : 購入フロー

購入時はクライアントが各プラットフォームのサーバに購入リクエストを送ります。購入OKであればレシート情報がプラットフォームのサーバから送られてきますので、クライアントはこれをモンストのサーバへと転送します。モンストのサーバでは送られてきたレシート情報に従ってモンパス会員権の有効化処理を行います。これは全プラットフォーム共通です(図1)。

 

継続時の処理はプラットフォームごとに異なります。

f:id:mixi_PR:20210129155807p:plain

図2 : 2ヶ月目以降の継続購入フロー(App Storeの場合)


App Storeでは、継続確認はクライアントが行います。クライアントはApp Storeサーバへ確認依頼を投げ、App Storeサーバは継続が行われていれば継続購入分のレシートを返します。以降は購入時と同じで、クライアントはレシート情報をモンストのサーバに投げ、モンストのサーバは受け取ったレシート情報に従ってモンパス会員権の有効期限を延長します(図2)。

f:id:mixi_PR:20210129160338p:plain

図3：2ヶ月目以降の継続購入フロー(Google Play Store・Amazon Appstoreの場合)

一方、Google Play Store・Amazon Appstoreでは、継続確認はモンストのサーバが行います(図3)。プラットフォーム側の継続更新が完了した頃合いを見計らってレシート情報を問い合わせ、購入が継続がされている場合はモンパス会員権の有効期限を延長します。

では、プラットフォーム側の継続更新が完了するのはいつでしょうか？プラットフォームの公式ドキュメントにはいつまでに契約更新が完了するかは明記されていません。そのため、モンパスにおいては契約終了日から2〜3日間 (契約終了の時間帯により変わります) を会員更新期間とし、この間に継続更新を試みることにしました。それでも継続が行われないケースについては、お客様からのお問い合わせ起点で対応できるようCS (Customer Support : カスタマーサポート)の体制を整えています。

モンパス継続によるインセンティブ

モンパスでは会員サービスの継続によるインセンティブを設けています。
継続インセンティブは1ヶ月毎、3ヶ月毎にあり(2018年3月14日現在)、どちらも購入日から指定期間以上契約を続けることが条件となります。例えば最初の1ヶ月の継続インセンティブは、モンパスを2018年3月1日0時に購入した場合では1ヶ月後の2018年4月1日0時まで契約を続けると受け取ることができます。

お問い合わせによって判明する契約日時の謎

お客様からのお問い合わせを直接対応するのはCSスタッフです。CSスタッフで解決できなかった問題はCREへ調査依頼として届けられます。

モンパスをリリースしてから1ヶ月半経った11月のある日、契約終了日が想定と異なるお客様がいらっしゃるということで、調査依頼が来ました。
これらのアカウントに共通しているのは購入日が10月1日、契約終了日が10月31日になっていることでした。利用されているプラットフォームはApp Store, Google Play Storeと異なります。

CREによる問い合わせ調査

実際にお客様のアカウントの契約終了日時がいつになっているか確認してみます。

  プラットフォーム 購入日時 契約終了日時
アカウントA App Store 2017-10-01 00:00:47 2017-10-31 00:00:47
アカウントB Google Play Store 2017-10-01 00:03:14 2017-10-31 02:03:04

公式ドキュメントには契約終了日はいつになると記載されているのでしょうか？
App Storeの公式ドキュメントには明記されていませんが、 Working with Subscriptions の契約例が記載された Table 6-1 を見ると

February 20 : User subscribes to a monthly subscription plan. The February issue is the most recent, and is made available immediately. March 20 : The user’s subscription automatically renews for another month. April 20 : The user cancels their subscription, thus ending the subscription period.

と書かれているので、購入日の翌月同日が契約終了日となりそうです。10月1日に購入したのであれば契約終了日は11月1日になると予想できます。

App Storeを利用している他のアカウントの契約情報も見てみましょう。

  プラットフォーム 購入日時 契約終了日時
アカウントC App Store 2017-10-01 18:09:20 2017-11-01 18:09:20

購入日時が同じ10月1日でも、契約終了日時が想定通り11月1日となるケースと、そうでないケースがあるようです。

勘の良い方はここで気づいたかもしれませんが、続けていきます。
ここまで記載した日時はすべて日本時間(JST)です。試しにアカウントAの購入情報を太平洋時間(PT)で見てみます

  プラットフォーム 購入日時 契約終了日時
アカウントA App Store 2017-10-01 00:00:47 JST 2017-10-31 00:00:47 JST
2017-09-30 08:00:47 PT 2017-10-30 08:00:47 PT

太平洋時間で考えると購入日時は9月30日で、契約終了日時は丁度1ヶ月後の10月30日になるので、ドキュメントどおりです。つまり、プラットフォーム側で契約期間を計算する基準となるタイムゾーンはそれぞれ独自に定義されており、サブスクリプションの提供国 (モンパスの場合は日本) の標準時とは異なるということです。
他のアカウントの契約情報をさらに詳細に調査した結果、 App Storeは太平洋時間を、Google Play Store・Amazon Appstoreは世界協定時間を利用していそうだということがわかりました。太平洋時間については、もちろんサマータイムを考慮する必要があります。

モンパス継続によるインセンティブへの影響

契約終了日が日本時間基準ではないとなると、モンパスにおいては継続インセンティブの配布に影響がでます。

f:id:mixi_PR:20210129160531p:plain

図4 : アカウントAの契約状況

アカウントAの場合、購入日時が 2017-10-01 00:00:47 JST 、契約終了日時が2017-10-31 00:00:47 JSTでした(図4)。
1ヶ月毎の継続インセンティブの受取条件は、購入日の1ヶ月後(2018-11-01 00:00:47 JST)まで契約を続けていることです。これは図4の例でいうと赤い矢印の長さが青い矢印の長さ以上になることと同義ですが、ご覧の通り受取条件を満たしていません。つまり、プラットフォーム上は1ヶ月間契約をしているのに、モンパスの1ヶ月毎のインセンティブを受け取ることができないというおかしな状況になっています。

 

この事実が発覚した2017年11月時点では1ヶ月毎の継続インセンティブは未実装で、3ヶ月毎の継続インセンティブしかありませんでした。また、不幸中の幸いで、まだリリース日から3ヶ月経っていなかったため、事前にインセンティブの判定処理に修正を入れることができ、事なきを得ました。

最後に

各プラットフォームで基準としているタイムゾーンの違いについて紹介しました。

 

プラットフォームの仕様についてはドキュメントが豊富にあります。開発環境も用意されていますので、動作テストも可能です。 しかし、ドキュメントで網羅されていない挙動も多くあることと、開発環境と本番環境で挙動が一部異なるケースがあることから、実際に本番環境で運用してみないとわからない部分が多々あります。

 

本記事で紹介したプラットフォーム毎のタイムゾーンの違いについても、公式ドキュメントには記載されていないところでした。
実際にサブスクリプション機能を実装・運用して得られた知見は (公式ではないのであくまで参考ではありますが) 貴重な情報で、有志の開発者によってブログやコミュニティ等様々な場で共有されています。本記事もサブスクリプション機能を利用する開発者の皆様の一助となれば幸いです。

 

明日3/15(木)は、田村より「ChatOpsによる解析基盤の運用改善とAWSクロスアカウント環境における実装例」を紹介いたします！

【CREウィーク火曜日】Zendeskまもるくんという社内ツールをオープンソース化しました

※こちらの記事は過去のブログから転載したものです。

初めまして、XFLAG スタジオCRE（Customer Reliability Engineer）チームの橋本です。

 

昨日から「CREウィーク」と題しまして、CREチームのメンバーが毎日日替わりで日々取り組んでいる業務についてブログで発信しております。

 

2日目は、先日私たちがOSSとして初めて公開したプロダクト、 「zendesk-incident-protector（社内通称: Zendeskまもるくん）」 について紹介させていただこうと思います。

 

Zendeskまもるくんは昨年末、Qiitaの弊社アドベントカレンダーで取り上げたユーザースクリプトで、今回のOSS化はそれを公開可能な形でリメイクしたものです。

 

リポジトリは下記になります。
https://github.com/xflagstudio/zendesk-incident-protector

 

ZendeskまもるくんはZendeskと呼ばれるCRMのためのプロダクトで、ユーザーへの返信で意図していない単語（社内向けツールのURLや無関係のプロダクト内の用語など）が含まれている場合にアラート出来るツールです。Zendeskまもるくんは誤案内を未然に防ぎ、顧客信頼性の一段階向上に一役買ってくれます。

 

ユーザーサポート業務において、私たちCREチームは「不安を抱えるお客様に寄り添う」という観点を特に大切にしています。そしてそれはXFLAGスタジオだけでなく、CSに関わる全てのプロダクトにそうあってほしいと願っています。このOSS化を通じて、そうした世界へと少しでも近づけたらと私たちは考えています。

 

もちろん、機能要望や改善提案などはいつでも歓迎しております:)

主な機能と仕組み

今回公開したユーザースクリプトは、技術的には下記のような処理フローによって動作しています。

f:id:mixi_PR:20210129152625p:plain

利用する際はまず初めに、

を定義したJSONファイルをインターネット上（AWS S3やGCP CloudStorageなど）に配置します。作動させるZendeskインスタンスは複数指定可能で、さらにNGワードについても各Zendeskインスタンス毎に個別に指定可能です。このため、複数のZendeskをホストしてサポート業務にあたっている場合でも、1つのJSONファイルで設定が可能です。
（詳細なJSONの構造についてはリポジトリのREADMEに記載しておりますので、この場では割愛させていただきます。）

 

NGワードのチェック機構を作動させたいZendeskの初回読み込み時には、上述のJSONファイルのURLをプロンプトから指定します。一度指定すればチケットフォームを表示するたび、パブリック返信（ユーザーへの返信）時にNGワードのチェック機構が動作し続ける状態となります。

 

Zendeskは一つの画面内で複数のチケット（問い合わせ等を起点としたやりとりを管理するスレッド）を表示することが出来るようになっており、各チケットはタブを通じて切り替えることが出来ます。この切り替えの際に、Zendeskの内部ではHTML5 History APIのpushStateを利用してURLを遷移させ、画面の表示を更新しています。この際に、返信フォームや送信ボタンのHTMLといった、ユーザースクリプトの監視やトリガーの対象となっている要素も書き換えられています。

 

このpushStateのイベントが発火されたタイミングで、必要であればNGワードのチェック機構をタブに対して追加する仕組みになっています。どのタブにチェック機構を追加したかはユーザースクリプト内で管理しているため、一度追加したタブへは再度追加されません。

おわりに

お問い合わせをいただいたユーザーとのコミュニケーションは、ユーザーからのメールとZendeskを介したサポートスタッフの返信からなるやりとりが全てです。そのため、返信を見たユーザーの心象でそのプロダクトの顧客信頼性が決まると言っても過言ではありません。

 

Zendeskまもるくんの導入前は、以下に挙げるような誤案内が累計で数十件ほど発生していました。

  • インシデント送信
    • 例: 社内用のツールのURLや内部用語、返信用のテンプレート
  • 漢字の誤表記（繁体字）
    • 例: ×幾率と○機率（「確率」を意味する漢字）

誤案内によってユーザーは不安を感じるかもしれない、それを技術の力で解決したい。そんな想いからZendeskまもるくんの開発は1年半ほど前から始まり、社内やパートナー企業のサポートスタッフに活用され続けてきました。誤った文面の送信をアラートを通じて防げるようになり、Zendeskまもるくんに設定されたNGワードを含む誤案内は、導入後1件も発生しなくなりました。

 

冒頭でも述べた「不安を抱えるお客様に寄り添う」ためには、ユーザーへの返信の中で未然に防げるリスクの芽は摘まないといけません。今回公開したOSSプロダクトには、そういった考え方に共感いただける個人や企業様にご活用いただき、更に発展させていければという想いがあります。

 

また、本ブログの記事が顧客信頼性という概念を知る切っかけになり、ひいてはCREコミュニティの活性化につながることを願ってやみません。

 

明日は同じくCREチームの上埜より「サブスクリプションのちょっと危険でディープな話」をお届けします。お楽しみに！

【CREウィーク月曜日】toC サービスの CRE における SLO の考え方

※こちらの記事は過去のブログから転載したものです。

はじめに

こんにちは。XFLAG スタジオ CRE チームの豊川です。
CRE ウィークと題して、今日から CRE チームのメンバー5名が月曜日から日替わりでそれぞれエントリを書いていきます。

以前、XFLAG スタジオでは CRE (Customer Reliability Engineer) というチームを設立し、サービスに対するユーザの信頼を高めるために取り組んでいるということをご紹介しました 。その背景には、サービスにおける顧客・ユーザの信頼が近頃ますます重要になってきているという実情があります。

本日初日のエントリは、事例がまだまだ少ない toC サービスにおける CRE において、私が考える SLO (Service Level Objective: サービスレベル目標) についてお話ししたいと思います。

CRE と SRE

Google の新しい専門職 : CRE が必要な理由 で、

Google では、お客様に対しても同じようなアプローチが必要だという結論に達しました。SRE の原理や教訓をお客様に適用すると、CRE にたどり着くのです。

と述べられている通り、CRE が生まれた背景には SRE (Site Reliability Engineer) があります。

まず SRE における SLO とは何かを見ていきましょう。

SLO, SLI, SLA

SLO がサービスレベル目標であるのに対し、SLI はサービスレベル指標 (Service Level Indicator)、SLA はサービスレベル契約またはサービスレベル合意 (Service Level Agreement) と呼ばれます。

SLO, SLI, SLA の関係性については、エラー・バジェットによるリスク管理 Managing risk with error budgets で次のように明確に説明されています。

SLI: 指標

SLO: SLI + 目標

SLA: SLO + 罰金

SRE における SLI には可用性、レイテンシ、耐久性等の指標があり、SLO は例えば「99.99% の可用性」というように設定されます。

SLO をそのまま CRE に適用できない理由

SREにおいては、SLO があれば、例えば「どの程度のダウンタイムであれば許容されるのか」といったことが議論できるようになります。

では CRE における SLO はどのように設定されるべきでしょうか？

優れた SLO を策定するには : CRE が現場で学んだこと では次のように述べられています。

ユーザー エクスペリエンスにおいて最も重要な側面を SLO が象徴するようにしなくてはなりません。SLO が満たされるということは、ユーザーにとっても自社にとってもハッピーなことでなくてはならないのです。

具体的な指標についてはここでは述べられていませんが、プラットフォームのような toB サービスであれば、ユーザにとってハッピーなことはインフラの可用性やレイテンシ、問い合わせに対するレスポンスなどが挙げられるでしょう。

一方、私たちのような toC サービスにおける CRE ではどうでしょうか？

これは非常に難しい問題です。

なぜなら一般的に toC サービスでは、私たちエンジニアがユーザ (ここではエンドユーザ) と直接やりとりすることはまずないので、SLO の設定にはまずユーザの定義から考える必要があるためです。

ユーザの定義

CREチームを設立しました！ では私たち CRE にとってのユーザには、エンドユーザだけでなく CS (Customer Support: カスタマーサポート) スタッフも含まれると述べました。

ここで問い合わせの流れを見てみましょう(図1)。

f:id:mixi_PR:20210205163116p:plain

ユーザからの問い合わせは、技術的な調査を要するもののみ CS スタッフからの調査依頼 (ここでは単にエスカレーションと呼ぶことにします) として CRE まで届けられます。

ここで、ユーザと CS スタッフ、CS スタッフと CRE の関係に注目してみましょう。

CRE が CS スタッフからエスカレーションを受けて対応する関係と、CS スタッフがユーザから問い合わせを受けて対応する関係は、見方によっては BtoBtoC と捉えることができます。

そこでここでは toC サービスの CRE における1つの例として、CS スタッフを私たち CRE のユーザであると仮定してみます。

次章では、CS スタッフをユーザとした上で、toC サービスの CRE においてどのように SLO を適用すれば良いか考えていきたいと思います。

toC サービスの CRE における SLO の適用

私たちは CS スタッフからのエスカレーション対応をどのように評価すべきか長年頭を悩ませてきました。

個々の案件ごとに難易度が異なるため、共通の指標を定義することができなかったためです。

この章では、今私たちが検討している SLI, SLO をご紹介し、具体的な参考値まで踏み込んでいきたいと思います。

toC サービスの CRE に適合する SLI は解決時間

SRE ではシステムの SLI として可用性やレイテンシ等が使われると述べました。

私たち toC サービスの CRE では、SRE におけるシステムの代わりに、CS スタッフのエスカレーションをあてはめ、可用性をエスカレーションの解決率、レイテンシをエスカレーションの解決時間に置き換えて考えてみましょう。

エスカレーションの解決率を SLI として SLO を設定することは、エスカレーションが解決しないケースを許容することと同義であることに注意しなければなりません。

なぜなら SLO には、

目標値 100 % というのは、どの時間幅においても不可能ですし、必要性もないでしょう。SRE は SLO を使ってリスクを容認します。

と述べられている通り、リスクを容認するという側面があるからです。

一方でエスカレーションの解決時間はどうでしょうか。

解決時間を SLI として SLO を設定することは、エスカレーションをなるべく短い時間で解決することの表明であり、これは先ほど挙げた「SLO が満たされるということは、ユーザーにとっても自社にとってもハッピーなことでなくてはならない」という SLO の原則にも合致しています。

そこでここでは、SLI をエスカレーションの解決時間とした上で、 次に SLO をどのように設定していけば良いか考えてみましょう。

SLO の値と考え方

SLI をエスカレーションの解決時間としたところで、次は SLO を具体的にどの程度の値に設定すれば良いかという疑問が浮かびます。

そこで私は、2017年10月から12月にかけて私たちが受け取ったエスカレーションを集計し、解決までにかかった日数と件数比率をグラフにしました(図2)。

f:id:mixi_PR:20210205163145p:plain
グラフから、半数以上の案件は3営業日以内に、3分の2の案件が5営業日以内に解決していることがわかります。また、3分の1の案件が2営業日以内に解決していることもわかります。

もしこれらの値を参考に SLO を設定するとすれば「3営業日以内解決率 50%」や「5営業日以内解決率 66.7%」となるでしょうか。

一方で、3分の1の案件が解決までに6営業日以上かかっていることもわかりました。
これらはシステムの不具合や障害に起因した、調査に時間を要するものです。

私たち CRE は、私たちだけで全ての技術的課題を解決できるわけではありません。このような問題に直面したとき、

エスカレーションは敗北を認めることではありません。SRE としては、開発チームの情報を検討し、解決までの時間が大幅に削減できるとある程度確信した段階で、すぐにエスカレーションするべきです。

でも述べられているように、私たち CRE もまた必要に応じて開発チームにエスカレーションします。

重要なのは、私たちの指標は全て私たちだけでコントロールできる性質のものではないと認識することです。

toC サービスの CRE における SLO とは、開発チームなど他部署と共にサービスを運営していることを意識しつつ、コントロール可能な範囲で最善を尽くせるように設定するのが望ましいと私は考えています。

おわりに

このエントリでは、SRE における SLI, SLO, SLA を紹介し、toC サービスの CRE における SLO の考え方についてお話ししました。

また、私たち XFLAG スタジオ CRE の実績をもとに、 SLI をエスカレーションの解決時間とした場合の SLO の参考値を紹介し、その考え方について述べました。
このエントリが toC サービスにおける他の CRE 事例の一助となれば幸いです。

 

明日火曜は橋本から「Zendeskまもるくんという社内ツールをオープンソース化しました」というタイトルで、私たち CRE 初の OSS に関するお話です。

TECH.C. 特別講演 登壇レポート 『最新のスマホアプリ開発の現場を支える技術』

※こちらの記事は過去のブログから転載したものです。

こんにちは。XFLAG スタジオ 人事戦略室のキャリア採用担当です。
XFLAG スタジオへの理解を深めていただくために発信している"XFLAG スタジオ活動報告"。

 

今回は、東京デザインテクノロジーセンター専門学校（以下、TECH.C.）様にお声掛けいただき、「卒業・進級制作展」の特別講演にXFLAG スタジオのテクニカルアーティストとエンジニアの3名が登壇した様子のハイライトをご紹介します。

はじめに

講演は90分間、テーマを「最新のスマホアプリ開発の現場を支える技術」として2部構成で企画しました。
第1部はエンジニアによるモンスターストライク（通称モンスト）のギミック実装について、第2部ではテクニカルアーティスト2名による対談で、テクニカルアーティストの役割や取り組みなどの紹介をしました。

 

当日の聴講者は、在校生、4月に入学を控えた高校生、一般の方々など80名超。ホール内のオープンスペースにステージが組まれていたため、通りがかりに立ち止まって聞く方々も多くいらっしゃいました。

第1部：モンストのギミック実装のお話

モンストシステムグループのクライアントエンジニア 角が、まずは「XFLAG スタジオ」と「モンスト」の簡単な紹介をしました。普段からモンストを楽しんでくださっているという方もいたおかげで、少し緊張がほぐれた様子。

f:id:mixi_PR:20210202203012j:plain

本題

そして本題であるギミック実装の話題に移ります。
資料はこちら。角が実装を担当したギミックの一部もご紹介しています。
（当日の資料から動画やスライドを一部省いたものとなります）

▲冒頭はXFLAG スタジオとモンストの紹介です

 

『案件が実装されるまでの大まかな流れ』はゲーム制作の一般的な流れに近いため、ご存知の生徒さんも多かったようです。ですが、毎回スムーズに進むわけでもなく、当然ながら周りへの影響も考えなければなりません。案件によってはいくつもの困難に直面するものだと、以下のような話もしました。

  • 新しく追加するギミックが既存の動作に影響を及ぼさないよう要注意。
  • 長規模な開発では、過去に実装された処理コードから意図や挙動を読み取る必要がある。
  • 仕様通りの実現を大前提にし、意図を理解してその一歩先を目指す。
    →XFLAG スタジオは「ユーザーサプライズファースト」つまり「お客様にまだ見ぬ驚きを届けること」を大切にしているため、「どうしたらユーザーさんが驚くか？」とワクワクを届ける視点が必要。ギミック実装もその姿勢で取り組んでいる。
  • コラボ案件では、コラボ先のキャラクターやその世界観がとても大事。その作品を研究しよく理解した上で取り組む。

 

普段なかなか話すことのない細かな内容でしたが、深く頷きながら聞く学生さんが多くいらっしゃったのが印象に残りました。

 

また、企画グループからの発案ではなく、エンジニアの角自身が提案したギミックが実際に採用された（※）、というエンジニアの枠にとらわれないXFLAG スタジオでの働き方についても話しました。
（※）角が考案したのはラグナロク神化の"フェイト・オブ・ザ・ゴッズ"！詳しくは資料をご覧ください。

f:id:mixi_PR:20210202203214j:plain

 

質疑応答の一部をご紹介

角が担当したとあるギミックについて、特定のケースを想定した質問がありました。（モンストをプレイしてくださっている方ならではの踏み込んだ質問！）


「（キャラがジャンプするという演出があるギミックにおいて）画面の上部でジャンプすると画面外にキャラが見切れてしまいそうですが、そのような場合はどうするのですか？」という質問でしたが、それに対しては「ジャンプして見切れる動きは納得できる挙動なので、問題なかった。」と回答。


更に、「問題となるケースが発生した場合も、企画グループやVFXチームと何度も相談して決めます。実際にユーザーさんがプレイした時にどう感じるのかは勿論のこと、修正方法やその修正にかかる時間、影響のある範囲なども材料に判断します」と補足しました。

 

XFLAG スタジオでは職種間の壁はなく、常に「ユーザーサプライズファースト」のために、様々な職種が心を一つにして取り組んでいることが伝わっていると嬉しく思います。

第2部：XFLAG スタジオを陰で支えるテクニカルアーティストの役割と取り組み

続く第2部では、XFLAG ARTS テクニカルアートグループのマネージャー下田と長舩の2名が対談形式で話をしました。

Technical Artistについて。そしてXFLAG スタジオのサービスとの関わりについて。

Technical Artist（TA）とは?に始まり、XFLAG スタジオでのTAの取り組みを、実際の動画や写真、アニメ映像を交えて話しました。
中でも「XFLAG PARK」での「モンストークライブ」については当日の舞台裏を詳しく紹介。聴講者の方の中には、実際にXFLAG PARKに足を運んだことがあるという方もいらっしゃいました。
また、TAの活動はXFLAG PARKに限らず、モンストアニメやアプリなどXFLAG スタジオが提供するサービスのほぼ全てに関わっていることについても触れていました。

AR/MR技術研究について

続いて、技術研究について。
TAの全業務量を"10"とした場合、XFLAGで現状走っているプロジェクトサポートに対しては"8"、技術研究に対しては"2"の割合で取り組んでいるとの事。サービスの礎となる研究にも、継続して取り組んでいることを話しました。
※XFLAG スタジオのMR（Mixed Reality）への取り組みはこちらのレポートでも簡単に紹介しています。是非ご覧ください。

f:id:mixi_PR:20210202203438j:plain

 

今後の業界展望

最後に、今後の業界展望について、注目しているツールやAIを活用したアートワークなど実例を挙げながら話しました。


長舩は、Tokyo Houdini meetupの発起人として活動していることもあり、その有用性についても詳しく紹介しました。
※先日、弊社にて開催したTokyo Houdini meetup vol.1のイベントレポートも公開中です。

 

f:id:mixi_PR:20210202203545j:plain

 

質疑応答の一部をご紹介

「テクニカルアーティスト」というハイブリッドなポジションを今日初めて知った、という学生さんからは、下田・長舩それぞれにエンジニアリングとアートどちらを専攻していたのか？という質問がありました。それに対して長舩は、芸術工学専攻でCGプログラマからキャリアをスタートさせたと回答し、下田はアートを専攻していたと回答。

 

異なる分野を学んだ二人が今では一つのチームで活躍していることからも、新しい文化が次々に創造され、技術の進歩が加速していく今後においては、ますますハイブリッドな人材が求められるのではないかと思います。

 

自身の得意分野以外にもアンテナを広げ、新しい文化や技術をキャッチアップすることがとても大切だと、長舩・下田は締めくくりました。

最後に

講演に熱が入り、終了予定時刻を少し過ぎてしまいましたが、皆さま最後まで熱心に耳を傾け、講演後も登壇者のもとへ質問に来てくださったりと、真剣な姿がとても印象的でした。

 

今後もこのような機会を頂けましたら、またぜひ伺いたいと思います。

 

XFLAG スタジオで活躍している社員のインタビューを掲載しています。
ご興味がありましたらぜひご覧ください。
https://career.xflag.com/interview/

JANOG41 Meeting in HIROSHIMA レポート

※こちらの記事は過去のブログから転載したものです。

こんにちは。XFLAG スタジオの杉田です。
少し前のイベントになりますが、JANOG41 Meeting in HIROSHIMA に参加してきたので、会場の様子などをご紹介させていただきたいと思います。

2018年1月24日(水)〜1月26日(金)の3日間、広島で行われた『JANOG41 Meeting』。

f:id:mixi_PR:20210219165916j:plain


福島で開催のJANOG40 Meetingに続き、今回は、ブレークスポンサーとして飲み物の協賛をさせていただきました。

f:id:mixi_PR:20210219170036j:plain


前回は、都合により、懇親会のみの参加で肝心の本会議に参加できなかったので、今回はどんなことを見たり聞いたりできるのか、ワクワクドキドキしながら、会場へと向かいました。

f:id:mixi_PR:20210219170125j:plain


前回のテーマは、"今までを振り返る、これからを知る"。
これまでの技術やネットワークオペレーターに求められているものを振返り、これから必要になる技術や能力、学ぶべきものを知ることで、時代の変化に対応していこうというものでした。

対して、今回のテーマは、"かきまぜる"。
前回のレポート(https://xflag.com/blog/report/janog40_meeting.html)でも書かせていただきましたが、物理的にも繋がっている、ネットワーク/インフラにとって、それを扱うオペレーター同士の横のつながりは非常に重要なことです。特に、最近では、ブラウザだけの世界に止まらず、様々なサービスやプロダクトがインターネットに接続され、また、動画などテクノロジーの進化と共に取り扱うデータ量も増えています。プレイヤーや取り扱う技術、インターネットを取り巻く環境も変わりつつある中で、新旧の技術や人同士がかき混ざり、お互いの想いや抱える課題を共有しあい、協力しあって、これからの時代を乗り越えていきたいという、今回のJANOG41の運営委員会の想いが感じられます。

今回のJANOG41で楽しみにしていたプログラムのひとつ、「初心者大歓迎! Light LightningTalk大会(https://www.janog.gr.jp/meeting/janog41/program/llt)」。
実は、入社4ヶ月の弊社島元が初心者LT枠で選ばれ、発表する機会をいただいておりました。

f:id:mixi_PR:20210219170301j:plain


この「初心者大歓迎! Light LightningTalk大会」は、若手にはなかなかハードルの高い本会議のプログラムや、それでもハイレベル、かつ、高倍率なLT枠に対して、これからを担う若手にも、壇上に上がる機会を与えようというもの。

島元からは、デモンストレーションも含めて、『手順書作成自動化したいLT (Junoser使ってみた)』というタイトルでお話しさせていただきました。
時間制限のある中でのデモで、焦っている島元に、会場からは「焦るな。大丈夫、大丈夫。」というようなあたたかい声を頂いたりして、このJANOGというのは、玄人から若手まで、様々な経歴の方々が集まって、インターネットの今と未来を考えて、真剣に議論を交わして、業界や技術者それぞれの成長を支えようとする、インターネットへの強い想いのある人達の集まりであると実感することができました。

その他のプログラムも、時間は限られてしまいましたが、興味深々で拝聴させていただきました。

中には、実際のネットワーク構成や取り組みに関する背景、諸事情、また、ネットワーク事業者による方針発表や、現在進行中の壮大なプロジェクトの中間報告や裏話など、オフレコなお話もあり、会場に来なければ得られない情報なども惜しげもなく共有されていました。そういった情報を共有できるのも、このJANOGに集まる人々が、お互いに組織の壁に関係なく信頼しあい、より具体的な事例をもって、日本のインターネット環境をより良くするために議論を交わそうとしているからとも考えられます。

f:id:mixi_PR:20210219170502j:plain


また、「突っ込みなど、何でもご意見ご感想を懇親会で教えてください。」「今は言えないですけど、お酒入ったら言ってしまうかもしれません。」などと冗談まじりに会場に投げかけたり、「議論の時間」と題して、壇上から「私はこう考えてこうしたけれど、皆さんはどうやっていますか？」「○○をやったことのある方？」などと会場に向かって質問が投げられたりと、単なる発表の場としてではなく、会議への参加者全員がその議題について考える場所として、大きなディスカッションの場のファシリテーターのような気持ちで壇上に上がられているのだと気が付かされました。

また、今回からは、全国各地からやってくる参加者同士のオンラインの交流の場として、専用Slackも用意され、開催前から、現地情報や会に関する情報などが展開されていました。

毎回毎回、会をより価値あるものにすべく、試行錯誤をされているJANOG本会議。
次回も今から楽しみです。

─────────────────────────
XFLAG スタジオでは、ネットワークエンジニアなど、
様々なポジションで仲間を募集しています。
https://career.xflag.com/career/
─────────────────────────

 

 

XFLAG活動報告vol.5：Tokyo Houdini Meetup Vol.1～ゲーム開発応用編～

※こちらの記事は過去のブログから転載したものです。 

こんにちは。XFLAG スタジオ 人事戦略室のキャリア採用担当です。
XFLAG スタジオへの理解を深めていただくため、発信している"XFLAG スタジオ活動報告"の第5弾。

今回は弊社にて開催した勉強会について、ご紹介します。

～ ＊＊＊ ～

昨年12月22日(金)、「Tokyo Houdini Meetup運営委員会」主催で「Tokyo Houdini Meetup Vol.1～ゲーム開発応用編～」を開催しました。

『ゲーム向けの機能が強化され、豊かな表現性及び多様性で話題になっているHoudiniが、XFLAG スタジオの開発生産性を向上させるのでは？？』というXFLAG ARTS　テクニカルアートグループの想いがあり、社内外問わず同様の想いをもった方々と一緒に"Houdini"について考える場を創りました。

当日は下記の方々にスピーカーとして、Houdiniの可能性や事例をお話いただきました。（年末のお忙しい時期にご登壇くださり、本当にありがとうございました！）

株式会社ポリフォニー・デジタル　齋藤彰様
株式会社セガゲームス　　　　　　伊地知正治様
元マーザ・アニメーションプラネット株式会社（現フリーランス）　鳥居佑弥様
日本デジタルゲーム学会理事　　　三宅陽一郎様


司会進行、そして自らも登壇し"Houdini"への想いを熱く語ったのは、XFLAG ARTS　テクニカルアートグループの長舩です。

それでは以下当日の様子をご覧ください。

～ ＊＊＊ ～

忘年会シーズン、且つ金曜日という状況下、、
いったい何名の方にお越しいただけるのか、楽しみ半分、不安半分で当日を迎えました。

f:id:mixi_PR:20210219180528j:plain

蓋を開けてみたら、なんと100名を超える方々が会場に！！
主催メンバーたちが「100名は集めたいですね」と話していたことが現実となり、改めて"Houdini"の熱量を実感しました。

まずは主催者・長舩より挨拶、今回のイベントの趣旨と、Houdiniを会社に導入するメリットをお話させていただきました。

f:id:mixi_PR:20210219180611j:plain

続いて、、

株式会社ポリフォニー・デジタル　齋藤彰様
「プロシージャルモデリングでのVoronoi有効活用法」

f:id:mixi_PR:20210219180656j:plain

Voronoi図を用いた様々なプロシージャルモデリング例を説明していただきました。シンプルな形状から複雑で魅力的な形状を自動生成するデモはHoudiniのプロシージャルモデリングの可能性を大いに感じることができました。最後に紹介のあった齋藤様のプロシージャルモデリングを応用したメカニカルな作品例は圧巻のクオリティでした。

株式会社セガゲームス　伊地知正治様
「龍が如く極2におけるHoudini活用事例」

f:id:mixi_PR:20210219181052j:plain

昨年12月に発売されたばかりのタイトル「龍が如く極み2」のHoudini活用事例を説明していただきました。Vertex Animation Texture（以下VAT）を用いたシャンデリアの破壊のデモでは、Houdiniでシミュレーションした複雑な破壊表現をゲームエンジン上でリアルタイムに再生できる最先端のゲーム開発事例を紹介していただきました。また、Houdiniを使用して銃の血痕や弾痕のテクスチャ生成事例を通じて、Houdiniの活用範囲の広さを知ることができました。

元マーザ・アニメーションプラネット株式会社（現フリーランス）　鳥居佑弥様
「Unity x Houdini 絵作りTips」

f:id:mixi_PR:20210219181641j:plain

最後に登壇していただいた鳥居様ですが、Houdini×GameEngineを組み合わせて映像制作を行う意義やHoudiniEngineを用いたUnityのTimeline上でVATを活用するテクニックを実際にシェーダーをライブコーディングしながら説明していただき、大変実践的なお話をしてくださいました。

5分休憩の後、
日本デジタルゲーム学会理事でありゲームAI開発者の三宅陽一郎様と弊社長舩との「AI×Houdiniの可能性」についてのスペシャル対談に入りました。

f:id:mixi_PR:20210219182127j:plain

長舩が立てた仮説「Houdiniと最新AI技術（Deep Learning等）を絡めるとより興味深い3Dアセット生成ツールができるのではないか」を基に対談は進んでいきました。対談中はProcedural Contents Generation（以下PCG）の歴史を振り返りながら、三宅様から様々な論文やAIのゲーム応用事例の紹介がありました。中でもGAN（Generative Adversarial Network）というHOTな画像生成技術の解説は（現時点ではまだ3Dへの応用は厳しい面はあるものの）会場内で特に注目されて盛り上がりを見せていました。

そして最後のセッションは「Houdiniパネルディスカッション～Houdiniマスターにいろいろ聞いてみよう！」。

f:id:mixi_PR:20210219182217j:plain

最初に登壇した3名のスピーカーとモデレータを務める長舩がHoudiniに関してパネルディスカッションを行いました。具体的にはゲーム開発のHoudini応用、プロシージャルモデリング、Houdini学習について話し合われました。実体験を基にしたHoudini導入の経験談や学習方法は、これからHoudiniを取り入れたいと考えている参加者にとって、参考になるヒントになるのではないかと思います。

19時に開始した今回の勉強会。
21時には終了し懇親会に入る予定でしたが、皆さんの熱量も高く、気がつけば22時前。。
参加された皆さんの熱心な表情が印象的でした。

少しでしたが、勉強会の後に懇親会も実施。
皆さん、技術談義に花を咲かせていらっしゃいました。

f:id:mixi_PR:20210219182324j:plain

会場は外の寒さとはうってかわり、参加者の皆さまの熱気で、終始かなり高い熱量でした。ご参加いただきありがとうございました。今後も、継続してこのような勉強会を開催していきたいと思います。

～ ＊＊＊ ～

XFLAG スタジオ XFLAG ARTS テクニカルアートグループでは、今回のようにスタジオ内の開発環境をより良くするため、またユーザーさんに夢中になって楽しんでいただけるコンテンツをXFLAG スタジオから創出するため、日々技術研究を行っています！

このグループで一緒に働くことにご興味がありましたら、ぜひご応募ください！
https://career.xflag.com/career/designer/798/


※テクニカルアートグループの取り組みを紹介した過去レポートはこちら。

XFLAG スタジオでは、その他デザイナー、クリエイターも積極採用中です。
https://career.xflag.com/career/#designer