ID:82208さん

DATUM STUDIO・ちゅらデータ(子会社)の全社共通IdP基盤として、Oktaを導入しました。 本プロジェクトの目的は、各SaaS/クラウドサービスのプロビジョニングに多くの工数をかけていた問題を解消することを目的とし、SCIMプロビジョニングをすることです。 必然的にステークホルダーが両社のコーポレートITや情シス、役員陣、労務など多岐にわたるため、 作業コストに加え、調整コストが非常に高いプロジェクトでしたが、目的達成以上の成果を上げて導入することに成功しています。 **実施内容** すでに導入していた、 ・Keeper ・SmartHR ・Envoy Visitors を、SCIMプロビジョニング・SAML SSOで連携させて全社へ同時にリリースしました。 マスタデータにはSmartHRのSCIM Syncアカウントによるプロビジョニングを採用しています。 これにより、社員の入社に合わせて自動的にOktaアカウントおよび、Keeperがプロビジョニングされます。 SmartHRのログインもOktaによるSAML SSOログインへ移行しました。 結果として、 ・社員のユーザビリティの大幅な向上。 ・セキュリティの大幅な改善。 ・労務・コーポレートIT・サービスプロビジョニング担当者・その他社員の、既存業務フローの大幅な効率化。 に寄与しました。 このプロジェクトでは、自分一人しか存在しないＰＪかつ、検証環境が存在しないため、非常に慎重な作業を要するため、レビュイーが必要でした。このため、支援をしていただける会社の選定にも携わり、準委任契約を締結しました。 リリースにあたっては、 ・起こりうる利用ケースを適宜ヒアリングし、要件定義。 ・必要なステークホルダーを巻き込みつつ、支援を活用。 ・非技術職でも理解が容易な手順書を用意。 ・あらかじめ一部の社員でベータ的にリリースし、最終全体テスト後のリリース。 これらを実施したため、安定したリリースに成功しました。 一部発生したリリース後のヘルプ対応も自分一人で実施しましたが、考慮漏れ事項なども特になく、大きな問題は発生させていません。原則、問い合わせがあってからの当日中の問題解決を実現し、社員からの対応スピードが評価されています。 また、Oktaの管理者サイドの運用効率化のため、 ・社員の入社・退社・休職・復職時の対応フローの策定。 　・最小限のフローの変更にとどめています。 ・インターン・契約社員・正社員・役員ごとの権限制御設計。 ・非コーポレートITでも理解しやすい非属人的ドキュメンテーション。 を実施しました。 今後、ほかのSaaS/クラウドサービス等の連携が容易になることと、 民主的なOktaの社内活用を目的として、 ・グループおよびグループルールの作成基準の策定をしました。 ・全社員が適宜利活用できるよう、管理権限付与のため、Jira Service Managementを活用した窓口の容易化。 　・hands-upした社員に、まずはsandbox等で自由に連携を実施させることで、案件のOkta活用時の社員のナレッジパワー向上。 　　・結果、連携できた各sandbox環境の棚卸コスト削減にも寄与。 　　・hands-upした社員向けにプレゼン資料を作成しデモ会を実施。 　・将来的には、例えば、ClaudeCode等を活用した、社内アプリの開発とリリースの加速に寄与の見込み。ODIC等でのSANL SSO・SCIMプロビジョニングを前提とすることが可能。 ・Okta Workflowを活用したSnowflake/Tableau等への従業員DB利活用の方針策定。 も実施しました。 その後、Slack・GoogleWorkSpace・EntraID・Box・Atlassian製品(Confluence・Jira)・その他各サービスの、Oktaによるプロビジョニングを実施しています。 既存の各SaaS等が保持している属性値や、サービスの運用状況を運用者や社員にヒアリングしながら、案件ごとの要件に合わせた要件定義、属性マッピングや権限設計の適宜見直し等を実施しています。 現段階では、まずは導入時のリスクの洗い出しを実施しています。

前職の知見を活かし、 ゲームタイトルのゲームインフラの運用上の問題点を解決、 費用的コスト・作業コストを抑え、業務の最適化に貢献する。 障害対応の実施等も行うが、障害を最初から起きないよう、現状の運用上の問題点へアプローチ。 特に、運用上の負債が非常に多く、属人化されたスパゲティな構成であるため、それが障害を起こしがちな原因となっているので、属人化をやめさせるように何度も働きかけていたが、文化的に遵守意識が全く根付かず、不可能であったため断念。 また、CentOS 7がEoLを迎える関係で、Ubuntuに移行するため、属人化して管理されていなかったものをIaCマネージドな環境にするため、チーム内のスキルレベルを上げようとしながら、2週間かかる業務を1日程度で用意できるようにする。 レビュー文化もない状態だったので、せめてそれはできていてほしいため、運用レベルで革新していこうとしている。

【プロジェクト名・内容】 非常に有名なIP巨大プロジェクトである実況パワフルサッカーの移管、新機能の他プロジェクトへの導入検討 cactiを利用するとのことでしたが、アラートをメンション付きでSlackに飛ばすという要件がありました。メールでの通知が前提なcactiでは、これは非常に難しく、IDCFクラウドへの移行だったため、IDCFクラウド特典のMackerelを利用し、無制限のホスト登録により、こちらをメインで利用することを提案しました。 この結果、cactiは、永続的にメトリックを保存するために利用し、Mackerelをメイン監視環境として利用する運用にできました。これにより、メンテナンス時、APIをMackerelに対し実行するだけで、アラート通知を一時的に無効化できるため、非常に運用がしやすい監視環境を実現しました。 また、メンテナンスに入れるスクリプトも私が作成いたしました。 移行 非常に大きいDBのバックアップファイルが何台もあり、いつも利用していたmysqldumpでは、メンテナンス時間6時間では確実に足りないほどの大きさでした。 先方は、データディレクトリを直接tarで固めたバックアップを取るようにしているようで、この取得でさえ非常に時間がかかります。 そのため、 1.バックアップを取る日のメンテ中に、先方からダンプファイルをいただき、手元のVMなDBサーバに展開して起動する。 2.先方のDBとレプリケーションを組ませてもらう。 3.IDCFのマネージドDBにVMDBからレプリケーションを組む。 これを、定期メンテごとに行い、最終的に30〜40台ほどのDBサーバすべてを、一貫性のあるレプリケーションをした状態にする。 移行当日までレプリケーションし続けているため、移行当日は、 1.メンテイン。 2.先方とのレプリケーション切断。 3.VMなDBとマネージドDBのマスターとスレーブを入れ替える。 これだけなので、当日メンテナンス作業の時間を非常に抑えることが可能だと見込み、検証した結果、2日〜3日かかる見込みだったメンテナンスが、6時間で完了しました。 本移行時も特に問題なく、検証通りの移行に成功しました。 また、本移行時のMySQLは、5.7系だったため、GTIDという仕組みと、いくつかのcrash safeなパラメータを導入しました。 こちらは先方のサーバでは導入していなかったため、先方とのレプリケーションが切れた後、本パラメータを追加しながら、マスタとスレーブを入れ替える対応となりました。 オペレーションがこれにより多少複雑化したのですが、これらのパラメータを入れると、レプリケーションの崩壊系の障害発生率が非常に下がることが想像できたため、提案をして、仕様を説明し、上長の許可を得て導入されました。 実際に、本パラメータがどのプロジェクトでも使われるようになってからは、レプリケーション崩壊系の障害は、ほぼ発生しなくなりました。(発生確率は数十分の1程度) 【技術環境】 IDCF MySQL Slack

【プロジェクト名・内容】 マルチクラウド利用での脱獄ごっこPROリリース 他社と協業の新規プロジェクトで、サーバレスでマルチクラウドでのゲームタイトルのリリースに携わりました。 先方の既存プロジェクトにあわせるため、このような新しい構成にチャレンジすることになりました。 サーバレスでPaaSを使うため、インフラとしての業務は無いかと思われていたのですが、実際にAPIを叩いてみると、負荷試験をしないと耐えられなさそうな箇所がいくつか見つかったため、急遽、GKEを用いて、開発チームに用意してもらったLocustを数千nodeで実行して検証しました。 AzureのFunctionsやCosmosDB等を使っていたため、それらのどこにボトルネックがあるかを、セルフホストなGrafanaサーバとAzure Insightsを見ながら確認し、スケール設定を変更しながら確認・チューニングを進めました。 限られたスケジュールの中で調査や、監視環境を始めとした様々な構築を確実に行い、無事サービスインに成功しました。 【技術環境】 GKE BigQuery Azure Playfab Azure Functions CosmosDB AWS S3

K8sベースタイトルの構築に関与。 ゲームタイトルの安定稼働のために負荷試験の実施や、IaC化、サーバチーム(バックエンド)との協力、課金認証基盤システムの連携を実施。 まずは魔法学園から始め、そのあとダンクロなどのタイトルのベースシステムとし、新規IPのタイトルリリースの円滑化に貢献。 現在リリースされている銀河鉄道もこれをベースにしている。

古くからのゲームタイトルゆえ、抱えるステークホルダーが多いため、既存ゲームの安定稼働のため保守運用に貢献した。 障害発生率の低減や自律的復旧の仕組み作りなどにより、かなりの運用負荷の軽減に繋げた。 また、利用するクラウドベンダは、国内クラウドベンダのため、システム移行も発生した。(GCP→IDCF、GMOアプリクラウド→IDCFなど) 特に大きい障害も発生させず、安定したシステム移行を達成。

【プロジェクト名・内容】 課金・認証システムのドキュメント整備・システム共通化 複数プロジェクトで共通で利用されている非常に重要なシステムにも関わらず、課金・認証システムの構築手順書が適切に整備されていないため、適切に手順書を更新しました。 私が、手順書が無い中でヒアリングしたことだけでデプロイを行い、必要なパラメータを伝え忘れていたとのことで、問題が発生し、開発版のデプロイを行ってしまいました。 これはそもそも非常に重要な事項なのに管理されていないことと、情報共有に問題があると指摘し、ドキュメントを何度もダブルチェックしながら整備しました。 また、この件に伴って、本システムを、同じレポジトリでプロジェクトごとに別ブランチで分けて管理する運用をやめ、利用方法の統一化とバージョンごとにタグを打って管理するように、少々規模が大きい革新的変更を開発チームに提案しました。 これまでは、各プロジェクト固有の設定が各ブランチで管理されていたことで、各ブランチでcherry-pickを何度も行わないといけなかったらしいのですが、今は全プロジェクトで最新のTagが打ってあるバージョンのシステムを導入すればよく、本当の意味での共通化ができました。 インフラチームの作業ミスが減り、開発側の負担も減らすことに繋がりました。 【技術環境】 GCP TencentCloud Terraform Ansible Git