SCSKクラウドソリューション の技術ブログ
全1226件
こんにちは、ひるたんぬです。 お店で買い物をした際に、クレジットカードを使うと、暗証番号を求められる機会があると思います。 …なぜ暗証番号って多くの場合4桁なのでしょうか？クレジットカードの他、ATMでもそうですよね。 ECサイトなどでのパスワードは英文字や記号を含めた複雑で、かつ多くの文字数を求められるのに、暗証番号に至っては今日でも4桁… 調べてみると、「世界初の暗証番号式ATM」は6桁の暗証番号だったようです。 その後4桁の暗証番号のATMが登場し、利便性（覚えやすさ）の観点から、4桁が主流になった…という経緯があるようです。 参考： 特定非営利活動法人 デジタル・フォレンジック研究会「コラム第８８６号：「暗証番号4ケタの起源～またはATMの歴史～」」 利便性の高さや覚えやすさの限界は確かにありますが、セキュリティの観点から、いつかこの暗証番号の制度も変わる日もくるのでしょうか… さて、今回は小ネタですがAWS CodeConnectionsを使おうと思ったときに、ちょっとしたところで引っかかってしまったのでご紹介いたします。 AWS CodeConnectionsとは？ そもそもこの名前に馴染みのない方もいらっしゃるかも知れません。 かくいう私も、この記事を書くまでは名前がつけられていることを知りませんでした。 AWS CodeConnectionsとは、サードパーティのGitベースのソースプロバイダ（GithubやGitLabなど）とAWSサービスを統合するためのサービスです。統合先としてはCodePipelineやCloudFormationなどが挙げられます。 AWS CodeConnections との製品とサービスの統合 - デベロッパーツールコンソール AWS CodeConnections と統合されているさまざまな AWS サービスとパートナー製品やサービスについて説明します。 docs.aws.amazon.com なお、元々は「AWS CodeStar Connections」と呼ばれたいたものですが、AWS CodeStarのサービス終了に伴い、2024年3月29日より名称が「AWS CodeConnections」に変更されました。 接続の名前変更 - 変更の概要 - デベロッパーツールコンソール 接続機能の名前変更の変更の概要を示します。 docs.aws.amazon.com ちょっとした罠とは…？ 題名にもありますが、このCodeConnectionsにセルフマネージド型のGitLabを連携させたかったのです。 今回連携させたいGitLabは「https://XXXXX-gitlab.com」といったようなURLだったため、それをエンドポイントに登録しようとすると… エラー文は、 The endpoint isn’t valid. An endpoint for cloud-based provider types cannot be used for hosts, which represent the infrastructure of installed provider types. To connect to a cloud-based provider type, create a connection directly. となっており、どうやらセルフマネージド型ではなく、クラウドベースのサービスのURLと誤認されているようです。 原因と対処法 今回の原因は、URLが「*gitlab.com」という形になっていることが原因ではないかと推察しました。 「推察」としているのは、そのような制約の存在がドキュメントなどには記載されていないためです。 GitLab セルフマネージドへの接続を作成する - デベロッパーツールコンソール コンソールまたは AWS CLIを使用して GitLab セルフマネージドへの接続を作成します。 docs.aws.amazon.com そこで、URLを変更し、「https://gitlab-XXXXX.com」としてみました。同じようにエンドポイントに登録しようとすると… 無事に接続が作成されました！ CodeConnectionsを利用するためには、この後に認証の作業（保留中の接続を更新）が必要です。 保留中の接続の更新 - デベロッパーツールコンソール AWS デベロッパーツールコンソールを使用して保留中の接続を更新します。 docs.aws.amazon.com 終わりに CodeCommitが復活したため、AWSとの統合の際にはCodeCommitを利用されることもあるかと思いますが、それ以外のソースプロバイダを利用される機会もまだまだあると思います。 本記事が同じような問題に遭遇した方のちょっとした手助けになれば幸いです。 AWS CodeCommit の今後について | Amazon Web Services 2024年7月、私たちは採用状況やお客様のニーズに関する評価に基づき、AWS CodeCommit の段階的に廃止する方針を発表しました。しかし、私たちはデータの分析やお客様の声を聞くことを止めていませんでした。そして、お客様が示してくださ... aws.amazon.com
TechHarmonyエンジニアブログでは、 AWS・Oracle Cloud・Azure・Google Cloud 各分野の受賞者 にフォーカスし、インタビューを通してこれまでの経歴や他の受賞者に聞いてみたいことをつないでいく「 リレーインタビュー 」をお届けしています。 第一弾は、「2025 Japan AWS Jr. Champions」 を受賞された 間世田 秀（ませだ しゅう）さん。 Japan AWS Jr. Champions は、AWSを積極的に学び、自らアクションを起こし、その取り組みが周囲にも良い影響を与えている若手エンジニアが選出されるプログラムです。 日々どのようにAWSと向き合い、どんな経験を積み重ねてきたのか。 そして、受賞に至るまでの背景には、どのようなキャリアストーリーがあったのでしょうか。 本インタビューでは、間世田さんのこれまでの経歴やAWSへの向き合い方、さらに「次の受賞者へ聞いてみたいこと」まで、じっくりとお話を伺いました。 プロフィール 2025 Japan AWS Jr. Champions 所属： ITインフラサービス事業グループ クラウドサービス事業本部 クラウドサービス第二部 氏名： 間世田 秀 【自己紹介】 2023年度入社後、AWS内製化支援サービス「 テクニカルエスコート 」のメンバーとしてお客様を支援させていただいています。 テクニカルエスコートでは、AWS導入検討から、設計、構築、運用改善まで幅広く内製化を後押ししつつ、お客様の課題解決に取り組んでいます。 本編 AWSエンジニアになった背景を教えてください。 もともと情報工学科出身でプログラミングに馴染みがあったため、アプリケーション開発希望で入社しました。 ただ、新人研修で改めてインフラ領域を学びなおしていくうちに、「 ネットワーク って パズルみたい でおもしろいな 」 と思ったことがインフラに飛び込むきっかけ になりました。AWSを初めて触ったのも、おなじく新人研修中です。AWSの持つシェアの大きさや豊富なサービス、そしてその柔軟性の良さに魅力を感じ、そこから、クラウドの中でもAWSを深く学びたいという思いが芽生えました。 研修後には 、 AWS内製化支援サービス「テクニカルエスコート」 チーム に配属 され、 AWSで課題を抱えたお客様と伴走しながら、共に課題解決に取り組む日々を送っています。 お客様と共に成長していく過程で、学ぶことの楽しさはもちろんのこと、複雑なシステムをシンプルに提供している点に魅力を感じ、AWSの奥深さを改めて認識しています！ エンジニアとして大切にしている価値観や信条はありますか？ 業務で必要な範囲にとどまらず、視野を広げるために最新技術を追い続ける姿勢を意識しています。今すぐ使う予定がなくても、知っていることで選択肢が増え、設計や提案の質を高めることにつながると考えているからです。近年は技術進化のスピードが非常に速く、アップデートが追いついていないと感じる場面もありますが、取り残されないよう頑張ってキャッチアップしています。 また、私たちは先人たちのアウトプットに多く支えられてきたと感じています。だからこそ、自分も 「巨人の肩に立つ」 だけで終わらせず 、 学んだことを言語化し、アウトプット として残すことを大切にしています。 言語化 することで 自分自身の理解が整理されるだけでなく、同じ悩みを抱えている人や、同じところでつまずいている人の助けになればと考えています。 ヨコのつながりを大切にすることも信条 の一つです。社内の他部署はもちろん、他社のJr. Championsとの交流を通じて、新しい発想やこれまで気づけなかった視点を多く得ることができました。そうしたヨコのつながりから生まれた刺激が、登壇や社内でのAWS活動といった次のアクションのアイディアにつながっています。 この度は受賞おめでとうございます！ 受賞に至るまで特に重点を置いて取り組んできたこと・乗り越えたチャレンジを教えてください。 受 賞の決め手は、苦手なことでも積極的に挑戦し続けたこと だと考えています。 人前で話すことは得意ではありませんでしたが、堂々と伝えられる自分になりたくて、イベント登壇への挑戦を重ねました。積極的に手を上げ続けた結果、登壇機会にも恵まれ、2024年度には登壇5回（社内2回・社外3回）の経験を積むことができました。 「 迷ったらとりあえず手を挙げる 」 を胸に、一歩ずつ積み重ねた 結果が評価につながったのだと思います。 受賞がご自身のキャリアやチームに与えた影響はありますか？ 受賞をきっかけに、2025年度から一部AWSマーケティング業務に携わらせていただいています。 マーケティングチームに参画したことで、我々の商材を外部の視点から見られるようになったことは大きな変化です。 プロモーション活動を通して外から見ることで、商材の良さや改善点を客観的に捉え直すことができたと思っています。 また、これまで技術職としてのキャリアしか考えていませんでしたが、マーケティングという新たな軸が加わったことでキャリアの幅が広がりました。 活動の中でAWS事業を どうビジネスとして発展させていくか を具体的に考える機会が増え、会社で働く上での マーケティングの視点の重要性を実感 しています。 この一年間は、年次を重ねていくうえで必要となる考え方を学ぶ貴重な機会だったと振り返っています。 今後、個人として、挑戦してみたい新しい技術・分野や、目指している目標について教えてください。 AWS/オンプレミスのネットワーク知識を身につけ、ネットワークアーキテクチャの提案についてチームの先輩方と同じ目線で議論できるエンジニアになりたいです。 テクニカルエスコートチームには、長年アプリケーション開発やデータセンターのネットワーク構築に携わってきたメンバーが多く在籍しており、AWSに限らない幅広い知識を持っている点が大きな魅力だと感じています。 AWS歴は3年目となり、 クラウドの設計・運用の経験 は増えてきましたが、 リフト＆シフト案件に携わる中で、オンプレミスのネットワーク知識不足を痛感 する場面がありました。また、オンプレミス歴の長いお客様に対しては、クラウド単体の説明ではなく、オンプレミスとの比較を交えて説明する方が理解・納得いただきやすいと感じており、そのためにも オンプレミスを含めたネットワーク全体の理解が不可欠だと考えています。 今後、AWSはもちろんですが、ネットワークを軸としたクラウドとオンプレミスどちらも積極的に学び続けていきます！ 次のインタビューは同じJr. Championsの「佐藤 優音」さんです！佐藤さんにお聞きしたいことはありますか？ 佐藤さんは、業務ではOracle Databaseを扱っているとお聞きしました。 AWS と Oracle 並行して、 学び続ける秘訣 を教えてください！ 間世田さん、ありがとうございました！ 最後に、読者の方へメッセージをお願いいたします！ 私自身が若手エンジニアの模範となるよう 、さらなるアウトプットを通じて皆様への良い影響を与えられるよう 挑戦 していきます！私の活動が同世代のエンジニアに広がり、そこから先輩・後輩との繋がりに発展していけば、「 クラウドに強いSCSK 」 の実現に寄与でき、お客様に還元 できると信じています。 次回インタビューは、2025 Japan AWS Jr. Champions を受賞された 佐藤 優音（さとう ゆうと）さんです。 次回の記事もお楽しみにお待ちください！
本記事では、グローバル環境におけるAWSクラウドリフトで、どのような点がポイントになるのかを整理します。 近年、複数の国・地域にまたがって事業を展開する企業が増え、それに伴い海外拠点のIT基盤をクラウドへ移行するケースも一般的になってきました。一方で、オンプレミスからAWSへのクラウドリフトは、国内案件とは異なる難しさを伴います。 では、グローバル環境でクラウドリフトを進める際、何が成功の鍵になるのでしょうか。 本記事では、イメージを掴みやすくするために、日本から海外の拠点を持つ日系企業のAWSクラウドリフトを支援するケースを題材に考えていきます。 なお、以下で紹介する内容はあくまで想定ケースとして整理したものであり、特定の実案件を示すものではありません。 技術面とプロジェクトマネジメントの両面から、グローバル環境ならではのポイントを整理していきます。 想定ケース 項目 内容 プロジェクト 日本から欧州圏に拠点を持つ日系企業に対して、海外AWS環境へのクラウドリフトを支援する想定ケース。 現状課題 欧州拠点のデータセンターで稼働している既存業務システムが対象。 構成はオンプレミス前提で、老朽化および運用負荷が課題となっている。 クラウド化の方針 アプリケーション改修は最小限とし、データセンターからAWSへのリフト（Rehost）を前提に移行を実施。移行期限が決まっている。 海外拠点の制約条件 現地のIT担当者は少人数で、設計や移行作業を主体的に進めるリソースが不足している。 プロジェクトの優先順位 制約条件を踏まえ、優先度は “ スケジュール ＞ コスト ＞ 品質” と設定。 想定ケースでありつつも、現実的に可能性が高いケースを設定しています。 技術的なポイント まずは、想定ケースにおける技術的なポイントを整理します。 1. リージョンとデータ所在 国内案件と違い、グローバル環境では「どのリージョンを利用するか」が前提条件になりやすいです。理由は、国・地域を跨ぐと次の制約が現実問題になるためです。 データ所在 ：個人データや業務データ、監査証跡（ログ）の保管場所が、国ごとの規制や社内ポリシーに影響されることがあります。 レイテンシ ：欧州ユーザーが使うシステムなのに、日本側設備（認証や業務連携、NW機器など）への依存が残ると、性能に影響します。 運用管轄 ：監査・セキュリティ・IT運用の責任主体が国別に分かれる場合、権限設計やログ閲覧の導線が変わります。 このため、設計の最初に「データはどこに置くべきか」「誰が何を閲覧できるべきか」「国境を跨ぐ通信は何が許容されるか」を前提として握っておくと、後戻りを減らすことができます。 2. 基本的な移行方針 クラウド移行では、いわゆる7R（Rehost / Replatform / Refactor / Repurchase / Relocate / Retire / Retain）のどれを選ぶかが最初の大きな分岐になります。 About the migration strategies – AWS Prescriptive Guidance このうち、優先度がスケジュール重視の状況では、移行方式はRehost（リホスト）が選ばれやすいです。たとえば次の条件が重なる場合です。 短期間でクラウド上の稼働を実現する必要がある 海外拠点のIT要員が限られている 既存アプリ改修や再設計に十分な時間を割けない リホストは構成変更を最小化できるため、工程を標準化しやすく、計画の不確実性を抑えやすいです。まずクラウド移行を完了させることに集中できる点は、スケジュール重視のプロジェクトで特に有効です。 一方で、リホストはオンプレ由来の設計（過剰な冗長化、運用前提の監視、固定的なサイジング等）をクラウドに持ち込みやすく、移行直後はコストや運用効率の面で余剰が生まれがちです。 そのため、リホストを採る場合は最適化（Replatform / Refactor など）を移行後フェーズに切り出す前提を、最初から計画に組み込むのが重要です。 3. 基本設計 グローバル環境のクラウドリフトでは、アカウント、ログ、ネットワーク、移行方式をまとめて設計することが重要になります。これらは相互依存が強く、個別に決めると後から手戻りが発生しやすいためです。 まず、マルチアカウント構成は運用整理だけでなく国・地域ごとに異なる監査要件や権限境界を吸収するための前提になります。特にログについては、運用用途だけでなく、監査や法規制の観点から「どの国・リージョンに保管するか」「誰が閲覧できるか」を最初に整理しておく必要があります。 ネットワーク面では、VPCの分割以上に国を跨ぐ通信経路と名前解決が難所になりやすいです。現行運用における拠点間接続や境界装置、DNS構成が曖昧だと移行時にトラブルになりやすいため、実際の状況から整理することが重要です。 移行方式としては、スケジュール優先のリフトではMGNを使ってEC2へ移行する構成が取りやすいです。ただしグローバル環境では、移行の成否はツールそのものよりも、国際回線の帯域やネットワーク機器の通信許可設定に影響することが多くあります。 4. パイロット移行 グローバル環境のクラウドリフトでは、パイロット移行は「成功させること」よりも、国を跨ぐ構成特有の論点を早期に洗い出すことが目的になります。特にネットワークや認証、名前解決などは、設計段階では見えにくい問題が出やすい領域です。 そのため、最初のパイロットでは、業務影響が小さく、依存関係の少ないサーバから移行を試す進め方が取りやすくなります。これにより、移行手順そのものの確認と、疎通・監視・バックアップといった周辺要素の論点を、短いサイクルで整理できます。 一方で、グローバル構成では、日本側設備や他拠点との接続が絡むケースも多いため、次の段階として国境を跨ぐ依存を持つ代表的なシステムをあえて対象にすることも重要です。こうした順序で進めることで、本番移行前に「どこが詰まりやすいか」を把握しやすくなります。 5. 運用設計 パイロット移行後は、運用をどう回すかが現実的な課題になります。 海外拠点が少人数の場合、現行オンプレミス運用をそのまま踏襲するのも、ゼロから日本的な重厚な運用を作るのもリスクになりがちです。 そこで、AWS Well-Architectedフレームワークをもとにベースとなる運用設計を作り、現地とのFit&Gapで調整する進め方が取りやすくなります。この方法であれば、AWS特有の責任分界や監視・ログの考え方を押さえつつ、現地で現実的に運用できる形に落とし込みやすくなります。 6. コスト最適化 スケジュール最優先のクラウドリフトでは、移行フェーズでのコスト最適化は最小限に留め、移行完了後のフェーズとして切り出す判断が現実的になりやすいです。移行と最適化を同時に進めると、作業が増えて遅延リスクが高まるためです。 ただし、グローバル環境では、国際データ転送や二重運用期間の影響で、想定以上にコストが膨らむケースもあります。そのため、移行フェーズではCompute Optimizerの有効化やタグ設計など、後から最適化を進めやすくするための仕込みを入れておくと効果的です。 こうしておくことで、移行後に十分な稼働データが揃った段階で、根拠を持ってサイズ調整や構成見直しに着手しやすくなります。 プロジェクトマネジメント観点でのポイント 次に、プロジェクトマネジメントの観点でポイントを整理します。 今回の想定ケースのようなグローバル案件では、技術そのもの以上に「伝え方」「合意の作り方」「前提の扱い方」が結果に直結しやすくなります。ここでは、特に影響が出やすい4つの観点に絞ってまとめます。 1. コミュニケーション管理 海外拠点支援はリモートだけでは現場の状況が見えづらく、前提のズレが後から発覚しがちです。 そこでプロジェクト初期は、可能であれば一度出張して現地の課題収集とリレーション構築を行う進め方が効果的です。キーパーソンや制約（人員、運用、ネットワーク事情）を早めに掴めると、その後のやり取りがスムーズになります。費用は掛かりますが、活用の仕方次第でそれ以上の効果を生み出せると考えています。 その後はリモート中心に切り替えて効率化します。海外拠点が少人数の場合、確認箇所を増やすほど相手が詰まりやすいので、日本側で論点を整理し「重要な点を中心に整理する」形が進めやすくなります。 コミュニケーションは時差の制約があるため、非同期的コミュニケーション中心になりますが、1日1時間で良いので会議体を設けることが重要です。重要論点はメールの往復よりも短時間でよいのでオンライン会議で擦り合わせる方が認識齟齬を減らすことができます。 特に状況が見えにくく、認識合わせが必要なフェーズでは必須になります。 2. スケジュール管理 グローバル案件は遅延要因が多くあります。時差による往復遅延、少人数リソースによる詰まり、多国籍メンバーの進め方の違い、国ごとの祝日・長期休暇などが典型です。 この前提があるため、計画では日本の感覚よりバッファを厚めに取ることが重要です。 3. 品質管理 相手拠点のAWS知見が少ない場合、日本側の支援比率が高くなります。そのとき品質を「分厚い資料」ではなく「読めて実行できる資料」と定義するのがポイントです。 日本の重厚なドキュメント文化をそのまま持ち込むと、相手にとっては過剰で「使われない成果物」になりがちです。 そのため、作るドキュメントの種類と粒度は最初にイメージを合わせ、全体が掴めるものと、手順が追えるRunbookなど、運用で使う前提の形に寄せると効果的です。 4. リスク管理 グローバル案件のリスクは、技術要因だけでなく境界とすれ違いから生まれやすくなります。 たとえば、日本側管理のネットワーク機器がボトルネックになる、担当者の長期休暇で止まる、祝日・時差で確認が遅れる、ドキュメント像のズレで手戻りになる、といったものです。 対策はシンプルに、目的・理由をセットで共有し、文字だけでなく図を使って認識を揃えることです。 重要な点ほど会話で短く合意し、決まったことは簡潔に残すという進め方がズレを減らします。 まとめ グローバル環境のAWSクラウドリフトで大変なのは、文化と環境が異なる相手との仕事で、技術的な点をを含めて前提が揃わない状態で物事が進みやすいところです。 国を跨ぐことで、ネットワークの疎通や切り分けが複雑化し、ログの保管場所や閲覧権限といった制約も絡んできます。加えて、海外拠点のリソース不足や時差により、確認や合意に想定以上の時間がかかることも少なくありません。 このような点に留意してクラウドリフトを進めることで、陥りがちな失敗パターンを回避することができます。 当社では技術伴走支援サービスで、クラウドリフトの支援も提供しています。 海外拠点を含むクラウド移行もご相談可能ですので、お気軽にご連絡ください。 AWS 内製化支援 ｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション
Dataformは、BigQuery上でデータ変換のワークフローを開発するためのGoogle Cloudのサービスです。 Dataformにはアサーションという機能があり、データ品質のテストを実装することができます。 今回はこのアサーションを利用して、直近一週間の対象のカラムにNull値が含まれているかを確認するアサーションを実装してみました。 概要 Dataformのアサーションについて Dataformには組み込みアサーションと手動アサーションがあります。 組み込みアサーション SQLXファイルのテーブルの config ブロックに追加する Dataformでテーブルを作成した後に実行される 以下を検査することができる nonNull ：対象の列にNull値がないこと rowConditions ：対象の列がカスタムロジックの条件を満たすこと uniqueKey / uniqueKeys ：対象の列に重複した値がないこと 手動アサーション 専用のSQLXファイルにSQLクエリを定義する 組み込みアサーションよりも複雑なロジックを実装できる クエリの実行結果が0件の場合は成功、1行以上ある場合は失敗となる 詳細についてはリンクをご参照ください。 データ品質のテスト | Dataform | Google Cloud Documentation Null値のアサーションは以下のように組み込みアサーションの nonNull でも実装可能です。 一方で、 nonNull で実装した場合、作成されたテーブルへの実行となるため、スキャン量が多くなってしまうことがあります。 config { type: "table", assertions: { nonNull: ["order_id", "quantity"] } } SELECT ... そのため、今回は直近１週間にアップデートされたデータにNull値が含まれているかどうかを手動アサーションで実装してみたいと思います。 実際にやってみる 以下のようなテーブルがあるとします。 order_date order_id quantity updated_at 2026-02-03 xxxxx 3 2026-02-01 13:30:00 2026-02-05 yyyyy 1 2026-02-03 10:00:00 2026-02-11 zzzzz 5 2026-02-10 18:00:00 今回は以下の通りに実装します。 直近一週間でアップデートされたデータをアサーション対象とすること order_id と quantity にNull値が含まれていないこと 実装したコード 2つのパターンで記述しています。 どちらもNull値が含まれていないことをチェックできます。 例1 該当するorder_id, quantity, order_dateを出力し、エラー原因の特定がしやすいクエリ SELECT * FROM `my_table` WHERE updated_at >= DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 7 DAY) AND (order_id IS NULL OR quantity IS NULL) 例2 件数だけのシンプルな結果を確認できるクエリ 以下のようにカスタムエラーメッセージを追加することも可能 SELECT COUNT(1) AS error_count, '直近1週間のデータのorder_id, quantityにNULL値が含まれています。件数=' || CAST(COUNT(1) AS STRING) AS error_message FROM `my_table` WHERE updated_at >= DATE_SUB(CURRENT_DATE('Asia/Tokyo'), INTERVAL 7 DAY) AND (order_id IS NULL OR quantity IS NULL) HAVING error_count > 0 まとめ 今回は、手動アサーションで直近1週間のデータにNull値が含まれているかどうかの検査をするアサーションを実装しました。 アサーションは、データの信頼性を担保し、分析や業務判断を支える重要な役割を果たします。 データの不備や異常値を早期に発見し対応することで、品質の高いデータを活用したビジネス上の判断ができるかと思います。 最後まで読んでいただきありがとうございました。
こんにちは。SCSKの池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念 これまでと何が変ったか！？ 今回は、LifeKeeper v10のライセンスについて解説したいと思います。 LifeKeeper for Windows版のライセンス体系 まず、LifeKeeper for Windowsの旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 ※LifeKeeper for Windowsのライセンス体系の一部となります 上の図のように、「LifeKeeper for Windows」には、v8の時と同様にLifeKeeper Coreと呼ばれるLifeKeeper本体とIIS ARK(Internet Information Services)、そしてRecovery Kit for PostgreSQLが含まれますが、さらに、ここに以下のデータベース用Recovery KitがLifeKeeper本体に含まれるようになっている点が大きな変更点となります。 ◆LifeKeeper本体に含まれるようになったRecovery Kit ・Recovery Kit for SQL Server ・Recovery Kit for Oracle Database またv8の時は、JP1/AJS Manager、Agent、HULFTとミドルウェアごとにARKが用意されていましたが、v10では 「Recovery Kit for Enterprise Application」に集約されている点も大きな変更点になります。 データベース用のARKが本体に統合されて、 その他のミドルウェアがRecovery Kit for Enterprise Applicationに集約されたのね LifeKeeper for Linux版のライセンス体系 今度は、LifeKeeper for Linuxの旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 Windows版よりも、新旧の関係が若干複雑になっていますね。 「LifeKeeper for Linux」には、v9の時と同様にLifeKeeper Coreと呼ばれるLifeKeeper本体とRecovery Kit for LVMが含まれますが、さらにこれまで単体のARKとして提供されていたRecovery Kit for Apacheが含まれるようになっている点が大きな変更点となります。 またv9の時は、JP1/AJS Manager、Agent、HULFT、IBM WebSphere MQはミドルウェアごとにARKが用意されていましたが、v10では 「Recovery Kit for Enterprise Application」に集約されています。 これまで物理サーバ構成で頻繁に使われてきたDMMPなどのマルチパス用ARKは パブリッククラウドでは使わないから、Recovery Kit for Basicとして別れたんだね まとめ このように「v10はライセンスが統一された」といっても、OSごとのこれまでの利便性を追求しつつ、ライセンス体系が見直されています。 ライセンス購入時は、できるだけサイオステクノロジー社から認定されたSI&サポートパートナーに確認をしたり、サイオステクノロジー社の公式ページを確認しながら必要なライセンスを選択するように注意が必要です。 サイオステクノロジー認定のSI&Supportパートナー （サイオステクノロジー公式サイト） Lifekeeperの製品体系 （サイオステクノロジー公式サイト） 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
業務でデータの不整合を調査したり、リリース後のデータ確認を行ったりする際、毎回同じようなクエリを書いていることに気づきました。 そこで、いざという時に焦らずコピペで使えるよう、データ調査でよく使うBigQueryのクエリパターンをまとめました。 【タイムトラベル】過去のある時点のデータを参照する データを誤って更新・削除してしまった時に使います。 バックアップテーブルからリストアしなくても、クエリに一行足すだけで過去の状態を参照できます。 ※タイムトラベル期間（デフォルト7日間）内であれば参照可能です。 SELECT * FROM `[プロジェクトID].[データセット名].[テーブル名]` -- 以下の時刻時点のデータを表示します FOR SYSTEM_TIME AS OF TIMESTAMP("2024-01-01 10:00:00+09"); -- ここに戻りたい日時を指定（JST） 【重複チェック】プライマリキーが重複していないか探す Step1：まずは重複の有無を検知する（GROUP BY） 「ユニーク（一意）であるべき項目」でグループ化し、数が2つ以上あるものを探します。 SELECT `[重複チェックしたいカラム名]`, -- 例: order_id, user_code など count(*) as duplicate_count -- 重複している件数 FROM `[プロジェクトID].[データセット名].[テーブル名]` GROUP BY `[重複チェックしたいカラム名]` -- SELECTと同じカラムを指定 HAVING count(*) > 1; -- 「件数が1より大きい（重複）」のみ抽出 GROUP BY: 指定したカラムの値が同じデータを1行にまとめる機能です。 Step2：重複行の全カラムを表示して差異を確認する（QUALIFY） 重複が見つかった後、「行ごとの登録日時はいつか？」「他のカラムに違いはあるか？」を確認するために、行を1行にまとめずに全カラムを表示します。 SELECT * FROM `[プロジェクトID].[データセット名].[テーブル名]` -- 「指定したカラム」ごとに集計し、2件以上ある行だけをフィルタリングして表示 QUALIFY count(*) OVER( PARTITION BY `[重複チェックしたいカラム名]` ) > 1 ORDER BY `[重複チェックしたいカラム名]`; -- 重複行が隣り合うように並べ替え QUALIFY: 集計した結果に対して、WHERE のように条件を指定して絞り込む句です。 PARTITION BY: 行を1行にまとめず、グループ集計するための機能です。 ORDER BY: 結果を並べ替えます。これがないと重複行がバラバラに表示されて比較しにくいため、指定します。 【異常値検知】データの偏りや異常値を調べる 「特定の値しか入っていないはずなのにエラーが出る」といった場合、想定外の値（空文字やNULLなど）が入っていないか確認します。 カラムに入っている値ごとの件数を集計します。 SELECT `[値の内訳を見たいカラム名]`, -- 例: status, category など count(*) AS count -- その値が何件あるか FROM `[プロジェクトID].[データセット名].[テーブル名]` GROUP BY `[値の内訳を見たいカラム名]` -- SELECTと同じカラムを指定 ORDER BY count DESC; -- 件数が多い順に並べる（異常値を見つけやすくする） DESC（降順）: 多い順に並べます。主要な値を把握したい時に使います。 ASC（昇順）: 少ない順に並ぶため、「数件だけ混じっているレアな異常値」を見つけたい時に便利です。 ＜Tips＞異常値が見つかった場合の修正例 本来 ‘0’ であるべき場所に、空文字（何も表示されない行）が見つかった場合の対処法です。 UPDATE `[プロジェクトID].[データセット名].[テーブル名]` SET `[修正したいカラム名]` = "0" -- 正しい値（例: "0"）に書き換える WHERE `[修正したいカラム名]` = ""; -- 異常値（例: 空文字）を条件指定 【環境比較】本番と検証でデータ件数に差がないか確認する リリース作業の前後や、本番環境と検証環境で「データが正しく移行できているか」を比較します。 2つのクエリ結果を結合して表示します。もし count の数が合わなければ、データ移行漏れや更新処理の不備が疑われます。 ※タイムトラベル期間（デフォルト7日間）内であれば参照可能です。 -- 環境A（例：本番）のデータ件数 SELECT '本番環境' AS env, count(*) AS count FROM `[プロジェクトID].[データセット名].[本番テーブル]` UNION ALL -- 環境B（例：検証）のデータ件数 SELECT '検証環境' AS env, count(*) AS count FROM `[プロジェクトID].[データセット名].[検証テーブル]`; 最後に これまではその場しのぎで都度調べてクエリを書いていましたが、こうしてまとめてみると それぞれの句の意味を改めて復習する良い機会になりました。 データ調査をスピード感をもって実施できるよう、皆様もぜひこのテンプレートを活用してみてください。
前回の記事 では、Bicepを用いたネットワークリソースの構築を実践いたしました。 Bicepを含むIaCを活用するメリットは、インフラの状態をコードで定義し、その構成を確実に再現できる点にあります。 そこで今回は、Bicepデプロイをより使いこなすために試した、2つのオプションをご紹介します。実際に試して分かった活用のポイントや、使用上の注意点についても併せてお伝えします。 オプション①：–confirm-with-what-if このオプションを設定することで、デプロイ実行前に差分確認を行うことができます。 現在の環境とBicepファイルの内容を比較し、どのような変更が発生するかを事前にシミュレーションできます。 Bicep の What-If: デプロイ前に変更をプレビューする - Azure Resource Manager Bicep ファイルをデプロイする前に、リソースに対してどのような変更が行われるかを確認します。 learn.microsoft.com 実行例 コマンドを実行すると、以下のように変更内容が可視化されます。 ターミナル上には、変更内容が色付きの記号で表示されます。 Create (+)：新規に作成されるリソース Modify (~)：既存の設定が変更されるリソース Delete (-)：削除されるリソース（Completeモード時など） NoChange (=)：変更がないリソース 表示内容に問題がなければ「y」で実行、想定外であれば「n」で中断してコード修正へ戻れます。 デプロイ前にこの差分をしっかりと検証することで、環境への予期せぬ影響を未然に防ぐことができます。 オプション②：–mode Complete このオプションを設定することで、コードを環境の正として管理することができます。 Bicepのデプロイモードには「Incremental（増分）」と「Complete（完全）」の2種類があります。 Incremental（デフォルト）：コードにあるリソースを追加・更新します。コードにないリソースが環境に存在していても、そのまま残ります。 Complete：環境の状態をコードと完全に一致させます。コードに記述されていないリソースは、デプロイ時に自動的に削除されます。 デフォルトはIncrementalですが、より厳格な構成管理を目指す場合にはCompleteモードが有効です。 デプロイ モード - Azure Resource Manager Azure Resource Manager で完全デプロイ モードと増分デプロイ モードのどちらを使用するかを指定する方法について説明します。 learn.microsoft.com ※補足：現在、MicrosoftではCompleteモードよりも、さらに安全にリソースの削除や保護を管理できる「デプロイスタック（Deployment Stacks）」の使用を推奨しています。Completeモードは強力ですが、影響範囲が広いため、より厳格かつ安全な管理を求める場合は、デプロイスタックの活用も検討してみてください。 Bicep で Azure デプロイ スタックを作成してデプロイする - Azure Resource Manager Bicep でデプロイ スタックを作成する方法について説明します。 learn.microsoft.com 実行例 コードの一部をコメントアウトし、Completeモードでコマンドを実行すると、以下のようにリソースの削除が行われます。 ①コメントアウト ここでは、削除したいリソースをコードから完全に消去するのではなく、コメントアウトにてデプロイを行いました。 あえてコメントアウトを利用することで、どのリソースを、どのタイミングで削除しようとしているのかという作業過程が明確になります。 ②デプロイ前 ③デプロイ実施 ④デプロイ後 Incrementalモードでは、コードにないリソースは「変更なし」と判断されて環境に残ってしまいますが、Completeモードであれば不要なリソースを確実に削除できます。 注意点 すでに運用されている環境でいきなりCompleteモードを適用すると、Bicepで管理していない共有リソースや、別メンバーが作成したリソースが削除されてしまうリスクがあります。 適用する際は、以下のルールを徹底することをおすすめします。 影響範囲の確認 Completeモードは、デプロイ対象のスコープ全体に影響します。 What-Ifとの併用 Completeモードを使う際は、必ず事前にWhat-Ifを実行し、削除対象に意図しないリソースが含まれていないかを確認してください。 まとめ 自動化されたデプロイにおいて、What-If による事前の差分確認や、Complete モードの仕組みを理解することは、作業の確実性を高めるための助けとなると考えます。 管理方法はプロジェクトの規模や方針によって様々だと思いますが、まずはこうしたオプションを試してみて、ご自身の環境に合った安全な構築・運用を検討してみてください。
本記事では、Azureのリソース管理ツールであるBicepを活用し、ネットワーク基盤をコード化してデプロイ（構築）する過程をご紹介します。 私自身、Bicepの実装は手探りからのスタートでしたが、その中で得られた構築プロセスを整理してまとめました。 Bicepをこれから触ってみたいと思っている方の、参考になれば嬉しいです。 Bicepとは Bicepは、宣言型の構文を用いてAzureリソースをデプロイするためのドメイン固有言語（DSL）です。 従来のARMテンプレート（JSON形式）と比較して可読性が高く、VS Code拡張機能による型補完やエラーチェックを活用することで、構築ミスを未然に防ぎながら少ないコード量で記述できる点が特徴です。 Bicepのより詳細な仕様や最新情報については、以下の公式サイトを参照ください。 Bicep とは - Azure Resource Manager インフラストラクチャを Azure にデプロイするための Bicep 言語を理解します。 JSON を使用してテンプレートを開発する場合に比べてオーサリングがしやすくなります。 learn.microsoft.com 今回作成するリソース 今回は、Azureインフラの土台となる「ネットワーク基本セット」を構築します。 複数のサブネットで共通のセキュリティポリシーやルーティングを適用する、実務でもよくある構成を想定しています。 作成するリソース ①仮想ネットワーク (VNet) × 1 2つのサブネットを含みます（今回は同じ役割のサブネットとして構築）。 ②ネットワークセキュリティグループ (NSG) × 1 共有設定として両方のサブネットへ紐付けます。 ③ルートテーブル (RT) × 1 共有設定として両方のサブネットへ紐付けます。 事前準備：開発環境を整える Bicepの作成をスムーズに進めるために、以下の3つのツールを準備します。 ①Visual Studio Code (VS Code) コードの作成・編集に使用するメインエディタです。 ②Bicep 拡張機能 (VS Code内) VS Codeにインストールすることで、コードの自動補完（型補完）や、記述ミスを教えてくれるエラーチェックが有効になります。 ③Azure CLI 作成したBicepファイルを、手元のPCからAzure環境へデプロイするために使用します。 Bicepコードを書いてみる Bicepには、複雑な構成を小さく管理しやすい単位に分割する「モジュール」という仕組みがあります。 今回は、将来の拡張性や再利用性を考慮し、単一のファイルにすべてを記述するのではなく、「全体を制御するメインファイル」と「各リソースを定義するモジュール」を分ける構成を採用しました。 ファイル構成 . ├── main.bicep # 全体の司令塔（各モジュールを呼び出す） ├── main.bicepparam # パラメータファイル（環境ごとの設定値） └── modules/ # リソース定義を格納するフォルダ └── network.bicep # ネットワークリソースの定義 この構成の大きなメリットは、管理がしやすい点にあります。 今後、ストレージやデータベースなど構築対象のリソースが増えていく場合も、 modules/ フォルダの中に storage.bicep や database.bicep といった形でファイルを追加していくことで、 シンプルに構成を拡張していくことが可能です。 Bicep モジュール - Azure Resource Manager この記事では、Bicep ファイルでモジュールを定義する方法と、モジュール スコープを使用する方法について説明します。 learn.microsoft.com 構築コード 以下の通り、コードを記述いたしました。 network.bicep（モジュール） ここでは、ネットワークの基盤となるリソースを定義します。 @description('リソースを配置するリージョンを指定します。') param location string @description('作成する仮想ネットワーク（VNet）の名前を指定します。') param vnetName string @description('VNet全体のアドレス空間（CIDR）を指定します。') param vnetAddressPrefix string @description('サブネット名の配列。各サブネットの名称とアドレスプレフィックスを含めます。') param subnetConfigs array @description('共通で適用するネットワークセキュリティグループ（NSG）の名前です。') param nsgName string @description('共通で適用するルートテーブル（RT）の名前です。') param rtName string // 1. ネットワークセキュリティグループ (NSG) の定義 resource nsg 'Microsoft.Network/networkSecurityGroups@2023-11-01' = { name: nsgName location: location properties: { securityRules: [] } } // 2. ルートテーブル (RT) の定義 resource rt 'Microsoft.Network/routeTables@2023-11-01' = { name: rtName location: location properties: { disableBgpRoutePropagation: false routes: [] } } // 3. 仮想ネットワーク (VNet) の定義 resource vnet 'Microsoft.Network/virtualNetworks@2023-11-01' = { name: vnetName location: location properties: { addressSpace: { addressPrefixes: [ vnetAddressPrefix ] } subnets: [for subnet in subnetConfigs: { name: subnet.name properties: { addressPrefix: subnet.addressPrefix // 作成したNSGとRTのIDを各サブネットに紐付け networkSecurityGroup: { id: nsg.id } routeTable: { id: rt.id } } }] } } main.bicep（メイン） 司令塔となるこのファイルでは、network.bicep モジュールを呼び出します。 具体的なパラメータの値は直接書かず、後述するパラメータファイルから受け取った値をモジュールへ渡す役割を担います。 targetScope = 'resourceGroup' @description('デプロイ先のリージョン。デフォルトはリソースグループの場所を引き継ぎます。') param location string = resourceGroup().location @description('VNetの名称を指定します。') param vnetName string @description('VNetのアドレス空間を指定します（例: 10.0.0.0/16）。') param vnetAddressPrefix string @description('サブネット構成情報のリストです。') param subnetConfigs array @description('共通NSGの名称です。') param nsgName string @description('共通ルートテーブルの名称です。') param rtName string // ネットワークモジュールの呼び出し module network './modules/network.bicep' = { name: 'networkDeployment' params: { location: location vnetName: vnetName vnetAddressPrefix: vnetAddressPrefix subnetConfigs: subnetConfigs nsgName: nsgName rtName: rtName } } main.bicepparam（パラメータファイル） 環境ごとの設定値（リソース名やIPアドレス範囲など）を記述します。 Bicepのパラメータファイルには、従来の「.json」形式と、新しい「.bicepparam」形式の2種類があります。 公式ドキュメントではどちらの形式もサポートされているため、既存の運用に合わせて選択して問題ありません。 今回は.bicepparamで記述いたします。 Bicepのデプロイメント用のパラメーターファイルを作成する - Azure Resource Manager スクリプトでインライン値としてパラメーターを渡すのではなく、Bicep パラメーター ファイルを作成する方法について説明します。 learn.microsoft.com using 'main.bicep' // --- ネットワーク基本設定 --- param vnetName = 'vnet-test-001' param vnetAddressPrefix = '10.0.0.0/16' // --- サブネット定義（同じ役割を担う2つのセグメント） --- param subnetConfigs = [ { name: 'snet-test-001' addressPrefix: '10.0.1.0/24' } { name: 'snet-test-002' addressPrefix: '10.0.2.0/24' } ] // --- 共通リソース設定 --- param nsgName = 'nsg-test--001' param rtName = 'rt-test--001' Bicepの記述に関する詳細な情報は公式サイトに多数掲載されており、以下に一部を抜粋いたします。 Bicep ファイルの構造と構文 - Azure Resource Manager 宣言構文を使用して、Bicep ファイルの構造とプロパティを理解する方法について説明します。 learn.microsoft.com Azure リソース リファレンス - Bicep, ARM template & Terraform AzAPI reference Bicep、Azure Resource Manager テンプレート、Terraform AzAPI プロバイダーを使用してリソースをデプロイするためのリファレンス ドキュメントを参照してください。 すべてのリソースの種類を表示します。 learn.microsoft.com デプロイの実行と結果の確認 リソースグループの作成 今回は最も一般的な「リソースグループレベル」でのデプロイを行うため、 デプロイを実行する前に、まずはリソースを格納するための「リソースグループ」をあらかじめ作成します。 # リソースグループの作成 az group create --name [リソースグループ名] --location japaneast Bicepファイルのデプロイ リソースグループが準備できたら、作成した main.bicep を展開します。 パラメータファイルを使用する場合は、コマンドの引数に –parameters を追加します。 # Bicepファイルのデプロイ実行 az deployment group create \ --resource-group [リソースグループ名] \ --template-file main.bicep \ --parameters main.bicepparam 実行結果の確認 デプロイ完了後、Azureポータルで対象のリソースグループを確認してみましょう。 画面を確認すると、VNet、NSG、ルートテーブルが1つのリソースグループ内に正しく作成されていることがわかります。 さらにVNetのサブネット設定を開くと、あらかじめ定義した通り、両方のサブネットに同じNSGとルートテーブルが紐づいた状態で出来上がっています。 まとめ 実際にBicepを触ってみて、これまでポータルで一つずつ行っていた作業がコマンド一発で完了する点に、自動化ならではの効率の良さを実感しました。 また、VS Codeの補完機能やAIを活用することで、詳細なリファレンスを読み込まずともスムーズに実装ができました。 IaC化によって管理のしやすさも向上するため、今後は他のリソースも順次コンポーネント化を進めていきたいと考えています。 Bicepに興味がある方は、まずは手近なリソースから触れてみることをおすすめします。
こんにちは。SCSKの谷です。 本記事ではAmazon WorkSpaces Pools について、とりあえず利用できるように最低限の設定を行い、WorkSpaces Client からWorkSpaces Pools へ接続するまでの手順を紹介しようと思います。 最低限の設定となるため、設定の詳細説明は省略しています。詳細については以下参考資料をご確認いただければと思います。 参考資料 今回WorkSpaces Poolsを使用するにあたり、以下のサイトを参考にしています。 Amazon WorkSpaces Poolsを試してみた | DevelopersIO SAML 2.0 を設定して WorkSpaces Pools ディレクトリを作成する – Amazon WorkSpaces 前提条件 以下を作成済みであることを前提とします。 VPC（NATゲートウェイ作成済み） Azure Portal のアカウント（無料登録可能） ⇒今回IdPとしてEntra IDを使用するため 概要 Amazon WorkSpaces Pools を利用するには、SAMLに対応したIdPとの連携が必要になります。今回はIdPとしてEntra IDを使用するため、AWSだけでなくEntra ID の設定も必要になってきます。 今回設定するサービスは以下になります。 Entra ID（エンタープライズアプリケーション） IAM ID プロバイダ IAMロール WorkSpaces プールディレクトリ WorkSpaces Pools 手順 １．Azure Portal へサインイン（Azure） Azure Portal へサインインし、[Entra ID]の概要からプライマリドメイン名をメモしておきます。 アカウントを登録していない場合は無料登録します。 ２．WorkSpaces プールディレクトリの仮作成（AWS） AWSコンソールより、[WorkSpaces]＞[ディレクトリ]＞[ディレクトリの作成]を選択します。 以下のように設定を行います。 WorkSpace タイプ： プール ユーザアクセスURL： https://dammy ⇒後続のEntra ID の設定が完了した後に再設定するため、一旦ダミー値を設定しています。 ディレクトリ名： 手順1でメモした Azure Portal のプライマリドメイン名 インターネットへのアクセス： チェックを外す VPC： 用意したもの（デフォルトでも可） サブネット： プライベートサブネット セキュリティグループ： デフォルトのセキュリティグループ 他の設定はデフォルトで、[ディレクトリの作成]をクリックします。 ３．Entra ID でエンタープライズアプリケーションを作成（Azure） エンタープライズアプリケーションを作成 Azure Portal へサインイン ＞[Entra ID]＞左ペインの[エンタープライズアプリケーション]＞[新しいアプリケーション]＞[独自のアプリケーションの作成]を選択します。 以下のように設定を行い、[作成]をクリックします。 アプリの名前： AWS WorkSpaces Pools（任意） アプリの操作： ギャラリーに見つからないその他のアプリケーションを統合します (ギャラリー以外) シングルサインオンの設定 次に、作成されたアプリケーションから[シングルサインオン]＞[SAML]＞[メタデータファイルをアップロードする]より、以下のXMLファイルをアップロードします。 以下URLよりXMLファイルをダウンロードします。 signin.aws.amazon.com/static/saml-metadata.xml アップロード後に表示される、「基本的なSAML構成」についてはそのまま[保存]をクリックします。 フェデレーションメタデータ XML の取得 次に、「SAML証明書」セクションより、「フェデレーション メタデータ XML」を[ダウンロード]します。 このXMLファイルは次の「IAMでのIDプロバイダの作成」で使用します。 ４．IAMでのIDプロバイダの作成（AWS） AWSコンソールより、[IAM]＞[IDプロバイダ]＞[プロバイダを追加]を選択し、以下のように設定しプロバイダを作成します。 プロバイダのタイプ： SAML プロバイダ名： EntraID-WorkSpacesPools（任意） メタデータドキュメント： 先ほど取得したフェデレーション メタデータ XML ファイル ５．フェデレーション用IAMロールの作成（AWS） IAMロールの作成 AWSコンソールより、[IAM]＞[ロール]＞[ロールの作成]を選択し、以下のように設定します。 信頼されたエンティティタイプ： SAML 2.0 フェデレーション SAML 2.0 ベースのプロバイダー： 先ほど作成したIDプロバイダ（EntraID-WorkSpacesPools） 許可されるアクセス： プログラムによるアクセスのみを許可する 属性： SAML:sub_type 値： persistent 許可ポリシー： 選択しない ロール名： WorkSpacesPools-SAML-Role（任意） その他はデフォルトで、一旦ロールを作成します。 IAMロールの「信頼されたエンティティ」の編集 IAMロール作成後、IAMロールの「信頼されたエンティティ」を編集します。 以下のように、”Action”内に”sts:TagSession”を追記して更新します。 インラインポリシーの追加 次に、作成したIAMロールにインラインポリシーを追加します。 追加するポリシーの内容は以下です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "workspaces:Stream", "Resource": "<WorkSpacesプールディレクトリのARN>", "Condition": { "StringEquals": {"workspaces:userId": "${saml:sub}"} } } ] } <WorkSpacesプールディレクトリのARN>は以下のように入力してください。 arn:aws:workspaces: ＜リージョン＞:＜アカウントID＞ :directory/ ＜WorkSpacesプールディレクトリID＞ 例） arn:aws:workspaces:ap-northeast-1:123456789098:directory/wsd-xxxxxxxxx ６．Entra ID エンタープライズアプリケーションの設定更新（Azure） 新しいクレームの追加・既存クレームの更新 再度Azure Portal に戻り、「属性とクレーム」セクションの[編集]を選択します。 （Azure Portal を閉じてしまった場合は、Azure Portal にサインインし[Entra ID]＞[エンタープライズアプリケーション]＞[作成したエンタープライズアプリケーション（AWS WorkSpaces Pools）]＞[シングルサインオン]より、「属性とクレーム」セクションの[編集]を選択してください。） [新しいクレームの追加]を選択し、以下を追加してください。 名前 ソース ソース属性 https://aws.amazon.com/SAML/Attributes/Role 属性 ＜IAMロールのARN＞,＜IDプロバイダのARN＞ https://aws.amazon.com/SAML/Attributes/RoleSessionName 属性 user.userprincipalname https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email 属性 Azure Portal 登録時に登録したメールアドレス 「https://aws.amazon.com/SAML/Attributes/Role」のソース属性については、手順4,5で作成したIAMロールとIDプロバイダのARNを”,”（カンマ）でつないだものを入力します。 例） arn:aws:iam::123456789098:role/WorkSpacesPools-SAML-Role,arn:aws:iam::123456789098:saml-provider/EntraID-WorkSpacesPools 続けて、「一意のユーザー識別子（名前 ID）」の内容を修正します。 「属性とクレーム」セクションの[編集]より「一意のユーザー識別子（名前 ID）」を選択し、以下のように設定します。 名前識別子の形式： 永続的 ソース： 属性 ソース属性： user.userprincipalname 「リレー状態」の追加 続けて、「基本的な SAML 構成」セクションの[編集]を選択します。 編集画面の下部にある「リレー状態」に以下の値を入力して保存します。 https:// ＜リレー状態リージョンエンドポイント＞ /sso-idp?registrationCode= ＜WorkSpacesプールディレクトリの登録コード＞ 例） https://workspaces.euc-sso.ap-northeast-1.aws.amazon.com/sso-idp?registrationCode=wsnrt+XXXXXX ※＜リレー状態リージョンエンドポイント＞については以下サイトより選択する。 SAML 2.0 を設定して WorkSpaces Pools ディレクトリを作成する – Amazon WorkSpaces ※＜WorkSpacesプールディレクトリの登録コード＞については以下より確認する。 利用ユーザの登録 続けて、エンタープライズアプリケーションの左ペインより、[ユーザーとグループ]＞[Add user/group]を選択してユーザを追加します。 今回は「testuser1」を追加しています。 ※ユーザについては、Azure Portal 上部の検索バーから「ユーザー」と検索し、[新しいユーザー]より新規作成できます。 ７．WorkSpaces プールディレクトリの本作成（AWS） AWSコンソールより、[WorkSpaces]＞[ディレクトリ]＞[手順2で仮作成したプールディレクトリ]＞認証セクションの[編集]＞[SAML 2.0 アイデンティティプロバイダーの編集]を選択し、以下のように設定します。 SAML 2.0 認証の有効化： チェック ユーザーアクセス URL： https://myapps.microsoft.com/signin/<エンタープライズアプリケーションID>?tenantId=<Entra IDテナントID> ※ <エンタープライズアプリケーションID> と <Entra IDテナントID> については以下より確認できます。 WorkSpaces Pools を作成するための事前準備は以上です。 ８．WorkSpaces Pools の作成（AWS） WorkSpaces Pools を作成していきます。 AWSコンソールより、[WorkSpaces]＞[WorkSpaceの作成]を選択し、以下のように設定します。 オンボーディングのオプション： 私は、自分のユースケースに必要な WorkSpace オプションを認識しています。 WorkSpace タイプ： プール 名前、説明： 任意の値 バンドル： Standard with Windows 10 (Server 2022 based) WorkSpace プールディレクトリ： 今回作成したWorkSpacesプールディレクトリ 今回は接続することが目的なので、その他の設定はデフォルトで[WorkSpace プールの作成]をクリックします。 WorkSpaceプールが停止済みで作成されるので起動します。（起動までに10分程かかります。） 状態が「実行中」になったことを確認し、「登録コード」をメモします。（「登録コード」は次の手順で使用します。） ９．WorkSpaces Pools へ接続する（WorkSpaces Client） WorkSpaces Client から、作成したWorkSpaces Pools へ接続してみます。 WorkSpaces Client がインストールされていない場合は以下よりインストールできます。 Amazon WorkSpaces Client Download WorkSpaces Client を起動し、WorkSpaces Pools の登録コードを入力し[Register]＞[Continue to sign in WorkSpaces]をクリックします。 ブラウザにてシングルサインオンの画面が表示されるので、Entra ID で登録した利用ユーザの情報を入力します。 ユーザ名は「ユーザープリンシパル名」を、パスワードは利用ユーザー作成時に設定したものを入力してください。 ※「ユーザープリンシパル名」はAzure Portal より確認してください。 少し待つと、WorkSpaces Client の画面に戻り、以下のように接続することができました！ 苦労したこと 初回設定後にWorkSpaces Client からWorkSpaces Pools へ接続を試みた際、WorkSpaces Client の画面に「Something went wrong」というエラーが表示され接続ができませんでした。原因としてはEntra ID 側での設定ミスだったのですが、エラーが詳細に記載されているわけではないため原因特定に時間がかかりました。。 接続がうまくいかない場合は、設定値の確認、VPCやセキュリティグループなどネットワークの確認をお願いします。設定値については環境によって手順通りではない可能性もありますので、公式ドキュメントや他の技術ブログなども参考にしてみてください。ネットワークとしては、インターネットへの経路があるか、インバウンドルール・アウトバウンドルールで特別な制限をしていないか等の確認をお願いします。 まとめ Amazon WorkSpaces Pools について、最低限の設定を行いWorkSpaces Client から接続をしてみました。 Poolsについては多数のユーザからの接続を想定したものになりますので、今回はデフォルト値としましたが、スケーリングの設定を行うことができます。今後はPoolsのスケーリング設定などをいじってみてどのようなスケーリングの挙動となるのか、またファイルはユーザ毎に保存できるのか等を試していければと思います。
こんにちは！ SCSK株式会社 小鴨です。 ServiceNowは何より重い…！そこの認識をごまかす輩は生涯地を這う…！ ということで本日はリリースについて必ず付きまとう課題、、、 データ移行 についての解説をさせていただきます！！ 多くの皆様にとっては釈迦に説法かもしれませんが そういった方はぜひ、コメントにてより高次元の使い方をご教示いただけると幸いです！ 更新セット以外のデータ取り込み なぜ更新セットにすべて入ってくれないのか。。。 開発環境にて様々な開発を行い、さあいよいよ本番反映だ！ となったときに、 あれ？この情報って更新セットに入らないの？ という疑問を持った経験はないでしょうか？ 例えば作成した「グループ」や「ユーザ」であったり グループに紐づいた「メンバー」や「ロール」といった情報は更新セットに入らず 別の方法を使用してテーブルへ直接取り込む必要があります。 今回はその中でexcelを用いた取り込みについてご説明します。 Excelインポートをしてみよう 今回は例としてグループテーブルに2つほどレコードを追加する場合を想定します。 まずは取り込み用のテンプレート取得から始めます。 ①「インポート」の選択 対象テーブルを開き、列名が並んでいる部分を右クリック するとアクション一覧が表示されますので「インポート」を選択します ②テンプレート取得 画面中央の「Excelテンプレートを作成」をクリックすることでダウンロード画面が表示されます。 (「すべてのフィールドをテンプレートに含めますか？」にチェックを入れると、テーブルが持つすべてのフィールドが取得するテンプレートに含まれ、チェックを入れなかった場合は前の画面に表示されていた列のみテンプレートに含まれます。) 「ダウンロード」をクリックすることでテンプレートのダウンロードが可能 ③テンプレート編集 以下のように、取り込みたい情報をExcelに記載していきます。 ※全て埋める必要はなく、入れる値がない場合は空欄でOK ④取り込み 再び以下の画面へ戻り、右クリックから「インポート」を選択。 進んだ画面で「ファイルの選択」から作成したテンプレートを指定し 「アップロード」をクリックします。 ⑤最終確認 この画面になったら「Preview Imported Data」をクリックします 進んだ画面で取り込もうとしたデータの数だけ「インポートセット行」というレコードが作成されているので 試しに開いてみると 以下のように、どこの値にExcelに入力した内容が反映されるか確認することができます ※想定と違う場所に値が入ることもあります。その場合は次回の記事を参照ください。 ⑥取り込み完了 問題なければ元の画面に戻り、画面下部へスクロールし「インポート完了」を選択します。 ※忘れやすいので注意！ 完了後、該当のテーブルを覗くと。。。 正しく入っていますね！これにてインポート完了です！ 次回予告 上のケースは何の問題もなく、とても平和に事が運んだ場合の紹介になります。 実際は値があべこべに入るような事象もいくらでもあります。 次回はそうした場合の対処法を紹介しようと思います。 「インポートセット」、「変換マップ」という概念にご興味のある方は是非お付き合いください。
SCSKの伊吹です。 今回はServiceNowのダッシュボードに触れてみたいと思います。 ダッシュボードとは？ 日々の業務を行っていると様々な情報が蓄積されていきます。 ServiceNowではレポートとしてそれらの情報を視覚的にわかりやすくグラフや表として表示できます。 しかしレポートが大量にあると確認したい情報に応じてあちこちのレポートを探す必要があります。 そこでダッシュボードという機能を使い、１つの画面の中に関連するレポートなどをまとめておくことで、その手間を省くことができます。 更に用途に応じて複数のダッシュボードを用意しておくことで、インシデント情報が見たければインシデント用のダッシュボード、問題情報が見たければ問題用のダッシュボードを選択することで素早く情報を得ることが出来ます。 ダッシュボードにアクセス ①ServiceNowにログインします。 ②アプリケーションメニューから[セルフサービス ＞ ダッシュボード]を選択します。 ③ダッシュボードの一覧が表示されます。 ServiceNowには導入時点で複数のダッシュボードが準備されています。 ④用途に応じたダッシュボードをクリックします。(ここでは例としてIncident Management) 各ダッシュボードには様々なレポートが紐づけられております。(下図で表示されているのは全体の一部です。) ダッシュボードを作ってみよう 前段ではServiceNowが予め用意していたダッシュボードにアクセスしました。 しかし「あのレポートとこのレポートを組み合わせることで、より自分の業務にあった使いやすいダッシュボードになるのに・・・」という要望が出てくると思います。 ここでは自分の用途にあったダッシュボードを作成してみたいと思います。 ①ダッシュボードの一覧画面の右上にある「新規ダッシュボードを作成」ボタンをクリックします。 ②「インラインエディター」を選択し、名前と説明を入力し、「新規ダッシュボードを作成ボタン」をクリックします。 ※「テクニカルエディター」を使うことでより詳細なカスタマイズを行えますが本投稿では割愛。 ③「新しい要素を追加」ボタンをクリックします。 ④「新しい要素を追加」ボタンをクリックし、追加したい要素を選択します。 ここでは「データの可視化」と「イメージ」を追加してみます。 ⑤「データの可視化」をクリックし、「保存済みの可視化」を選択します。 ※自分で新しい可視化(=レポート)を作成したい場合は「新しい可視化」を選択します。 ⑥登録されているレポートの一覧が表示されます。 例として「Incident created (by priority)」を選択し、「ダッシュボードに追加」ボタンをクリックします。 ⑦続いて④の画面から「イメージ」をクリックします。 画面右側に構成画面が表示されますので、「Choose a custom image」をクリックして表示させたい画像を選択します。 ⑧画面に追加した要素が表示されたのを確認し、「保存」→「編集モードを終了」をクリックします。 ⑨ダッシュボード一覧を確認すると、作成したダッシュボードの名前が表示されます。 名前をクリックすると先ほど作成したダッシュボードが表示されます。 まとめ ServiceNowのダッシュボードについて紹介しました。 ServiceNowには様々なダッシュボードやレポートが最初から登録されていますので、まずはどんなものがあるのか覗いてみてください。 その上で自分にあった組合せがない場合は、オリジナルのダッシュボードを作成してみては如何でしょうか。
SCSKの畑です。 とある案件において 他クラウド IaaS 上の Redis から Amazon Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。 背景 前回のエントリでも軽く触れた通り Redis は KVS のため、例えばキャッシュのような揮発性の高いデータのみが格納されているようなケースではデータの移行要件がないこともありますし、移行対象のデータがあるとしても新しく立てた Elasticache にアプリケーション/バッチなどから必要なデータを改めて入れ直すなど、現行の Redis からデータを移行する必要がないことも多いと思います。 ただ今回の案件については、現行の Redis からデータを移行する要件がお客さんとの会話等などから明確であったため、それを踏まえて Redis から Elasticache（Redis OSS）へのデータ移行方式を検討することとなりました。 なお、当初は Elasticache（Valkey）への移行も検討されましたが、今回の案件では非互換の可能性を極力排除して AWS への移行（リフト）のみにフォーカスしたいというお客さんの意向もあり、Redis OSS を採用することとなりました。 Amazon Elasticache の移行方式 Elasticache への移行方式は以下3種類となります。一括移行 or 初期移行＋差分移行という考え方そのものは RDBMS などと同じですね。 ちなみに、初期移行は差分移行を開始する前に現行環境から新環境にデータを移行する工程、差分移行は現行環境の更新データを初期移行直後の時点から新環境に対して継続的にレプリケーションする工程をそれぞれ指します。一括移行は言葉通りの意味ですね。 一括移行 初期移行＋差分移行（AWS マネージド） 初期移行＋差分移行（RIOT などの外部移行ツール） 当初は初期移行＋差分移行の選択肢として DMS を使えると思っていたのですが、改めて調べるとサポートされているのは移行ターゲットのみであることが分かり、今回のケースでは採用できませんでした。 Sources for AWS DMS - AWS Database Migration Service Use the listed data stores as sources for different AWS DMS features. docs.aws.amazon.com Elasticache における一括移行は、移行元の Redis で save コマンドなどで rdb ファイルのバックアップを取得して S3 に転送・配置した上で、そのバックアップを使用して新しく Elasticache のインスタンスを立ち上げる流れとなります。 バックアップから新しいキャッシュへの復元 - Amazon ElastiCache Valkey から既存のバックアップを新しい Valkey キャッシュまたはノードベースのクラスターに復元し、既存の Redis OSS バックアップを新しい Redis OSS キャッシュまたはノードベースのクラスターに復元できます。また... docs.aws.amazon.com 対して、初期移行＋差分移行の方式は、AWSマネージドの方式と、RIOTなどの外部移行ツールを使用する方式の2種類があります。AWSマネージドの方式については、以下 AWS ドキュメントに一通りの記載があります。 Valkey または Redis OSS のオンライン移行 - Amazon ElastiCache オンライン移行を使用して、セルフホスト型 Valkey または Redis OSS から Amazon ElastiCache にデータを移行します。 docs.aws.amazon.com 外部移行ツールを使用する場合は、ある意味当然ながらそのツール仕様に準じます。今回移行方式としては採用しなかったのでざっくり調べた程度ですが、ツールとしては Redis 公式？の RIOT が最もメジャーなようです。 Redis Input/Output Tools (RIOT) redis.github.io 必ずしも Elasticache 固有の内容ではありませんが、それぞれの移行方式の特徴についても簡単にまとめておきます。 一括移行 メリット 移行（切替）当日に移行対象の全データを現行環境から新環境に移行する方式のため、初期移行＋差分移行と比較して相対的に手順がシンプル 移行に要するトータルの工数も（一般的に）少ない デメリット 移行（切替）当日の所要時間・工数は初期移行＋差分移行と比較すると多くなる このため、移行（切替）時のスケジュールが一括移行の所要時間に収まらない場合は、スケジュールを見直す or 初期移行＋差分移行方式を採用する、の2択となる 初期移行＋差分移行 メリット 一括移行と比較して、移行（切替）当日の所要時間・工数は少ない 差分移行に使用する製品・サービス（例えば DMS など）によっては差分移行中に現行環境/新環境間のデータ整合性チェックを実施することも可能 移行（切替）当日に現行環境/新環境間でデータの整合性をチェックできるのが理想だが、移行対象のデータが大きい場合は移行（切替）時のスケジュールに収まらなくなる可能性があるため、このような方式で整合性チェックを行うことも選択肢に入ってくる デメリット 移行方式における制約や注意すべき事項が多い 初期移行において現行環境からデータを移行する際、現行環境への影響を考慮の上で具体的な方式・手順を決定する必要がある 初期移行は現行環境のシステムが稼働している状態で実施することが方式の特性上ほぼ前提となるため 逆に言うと、初期移行時に現行環境のシステムを停止できるのであれば事実上一括移行が可能と言えるため、この移行方式をわざわざ採用する必要がない 差分移行に使用する製品・サービスにおける各種制約に抵触していないかを確認する必要がある 制約に抵触することの影響度合いはケースバイケースだが、方式自体の採用可否に影響する場合もある 差分移行の特性上現行環境と新環境が相互通信できる必要があるため、通信経路の確立や帯域制限などが方式上のネックになる場合もある 上記内容も相まって、移行に要するトータルの工数は（一般的に）多い 今回採用した Amazon Elasticache の移行方式 結論から言うと、今回は「一括移行」を採用しました。上記で移行方式の特徴をまとめた通り、一括移行の採用可否は実質的に移行（切替）当日の想定スケジュールに一括移行の所要時間が収まるかどうかですが、検証環境で時間を計測したところ無事に収まりそうなことが分かったためです。具体的な所要時間の試算は以下のような流れで行いました。 ちなみに今回はデータベース（MySQL）の移行も同時に行うのですが、時間的にはそちらがボトルネックになるということも理由の一つでした。データベースの移行所要時間内に収まっていれば大丈夫だろうということで。 まず、今回移行対象となる Redis は 2 個あります。キャッシュサイズはそこそこ差があり、大きい方が約 100 GB だったため、ほぼ同じサイズのキャッシュデータをオンプレミス仮想環境上の Redis に用意した上で、Redis から rdb ファイルにバックアップする所要時間、及び S3 上のバックアップを Elasticache for Redis OSS にリストアする所要時間をそれぞれ計測しました。 Redis から rdb ファイルにバックアップ： 20 分 rdb ファイルのサイズは約 98 GB お客さんの IaaS 環境上ではもう少し早くなりそうですが（10-15分程度）、試算では上記計測値を使用 S3 から Elasticache for Redis OSS にリストア： 35 分 インスタンスサイズは cache.r7g.8xlarge 一括移行の所要時間としては上記に加えて Redis サーバから S3 へのバックアップファイル転送時間がプラスされますが、こちらはお客さんの IaaS 環境上で試算したところ 20 分程度見ておけば良さそうということで、合計で 20 + 20 + 35 = 75 分となりました。もう 1 個のキャッシュサイズは小さいため、トータルの所要時間への影響はほぼないと判断しています。 また、先述の通りバックアップを使用して Elasticache インスタンスを新しく作成する手順となるため、作成後に単体テスト・動作確認を実施する方針となりました。直列で作業する前提で 1 個につき 30 分かかるとしても 2 個で 60 分、合計すると 135 分 となります。 移行（切替）当日の想定スケジュールにおいて、データベース/Elasticache の移行に使用できる時間は 最大 6 時間 であるため、無事 Elasticache については時間内に一括移行できる見立てとなりました。 ただし、一括移行において「 バックアップを使用して新しく Elasticache を作成する 」という手順（仕様）により別の課題も想定されたため別途対策が必要になりました。そのあたりの話はまた別エントリでしたいと思います。 なお、このような検討過程であったため差分移行については真剣に検討するまで至らなかったのですが、ざっくり調査した内容及び所感を以下にまとめておきます。（真剣に検討していないのであくまでも参考程度で・・） AWS マネージド 初期移行および差分移行の両方をカバーしており、使用方法自体も非常に簡単 そもそもコンソール/コマンドから設定できる項目も必要最低限（実質的に移行元 Redis への接続情報のみ） https://docs.aws.amazon.com/cli/latest/reference/elasticache/start-migration.html その反面、使用に際しては様々な制約があるため、特に本番環境の移行で使用できるケースは限定的と思われる 特に「 転送（接続）時のSSL無効化 」や「 認証の無効化 」が必要なため、移行元の Redis でこれらの制約を満たさない場合は使用できない（今回の案件でもこの時点で採用 NG） https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/Migration-Prepare.html 移行対象の論理データベースやデータをフィルタリングするような機能はない レプリケーション開始時にターゲットとなる Elasticache のキャッシュデータが削除される仕様も良し悪し レプリケーションが失敗した場合の再試行自体は行いやすい反面、失敗した時点から再開するようなことはおそらくできないものと思われる（自動復旧した場合は別かも？） 外部ツール（RIOT） AWS マネージドの場合と比較して、認証や転送（接続）時の SSL が有効な場合も対応可能 RIOT が動作する中間サーバを用意する必要あり レプリケーション動作モードに scan と liveonly、及び 両方を併用した live の3種類がある scan は実質的な初期移行、対象の key や type、回数などをオプションとして指定可能 liveonly は実質的な差分移行（レプリケーション）だが、ドキュメント曰くデータの整合性を保証しないとのこと NW 障害時に Redis 上データの更新通知を RIOT が受け取れなかったり、Redis 上の大量データ更新時に Redis 自身が大量データの更新に追随できない（更新通知を送れない）可能性がある レプリケーション動作時の挙動も dump/restore コマンドを使用するモード、及びデータタイプにより異なるコマンドを使用するモードの 2 種類がある模様 こちらは特別な理由がない限り前者で良さそう（デフォルトも前者） もし今回の案件で使用せざるを得ない場合は上記制約との兼ね合いで RIOT になりますが、設計には正直骨が折れそうです。。 ちなみに RIOT 自体はメンテナンスを終了しており、後継ツールとして RIOT-X が開発されているようです。 RIOT-X :: RIOT-X redis.github.io まとめ Elasticache に限った話ではありませんが、このようなデータ移行についてはまず一括移行できないかどうかを優先して考えるべきです。逆に言うと、初期移行＋差分移行は対象システムの重要度や特性に基づく移行要件、及びデータ量などを鑑みた場合に（ある意味）やむを得ず選択する方式というくらいの位置づけで考えて良いと思っています。もちろん、DMS を始めとして初期移行＋差分移行に使用できる製品・サービスはここ 10 年くらいで大分充実してきているので、取り得る選択肢が広がっているのはいいことですが。 最も、Elasticache（Redis）はインメモリベースであるため、一般的な RDBMS のようなディスクベースの製品・サービスと比較して相対的に高速にデータ移行できるであろう点も踏まえると、一括移行する方針により倒しやすいとは思います。。 本記事がどなたかの役に立てば幸いです。
最近、EC2によるWebサーバの構築にあたり、ダッシュボードを使う機会があり、大変便利だということに気づきました。 今更ながらですが紹介します。 EC2に限った話ではありませんが、例として読んでください。 EC2の監視項目について EC2を監視するにあたり、監視する項目は一般的には以下のようなところでしょうか。 標準メトリクス CPU使用率やEC2のStatusCheckFailedなど カスタムメトリクス メモリ使用率や、cloudwatch logs に転送したログに定義したメトリクスフィルターによるものなど OS/MWログ cloudwatch agentでログを転送しているケースで、特に特定ワードでエラーを検知しているようなケース 各種アラーム 上記のメトリクスなどに設定したアラームのステータス これらをあれこれ見たい場合は画面の遷移が多くなり、思った以上に面倒です。 見る項目は大抵決まっていますが、いちいち対象を選択しないといけないのも面倒です。 ダッシュボード例 サンプルサーバで上記をカバーするダッシュボードを作成してみました。 例として、CPU使用率(標準メトリクス)、メモリ使用率(カスタムメトリクス)、サンプルのアラームステータス、および転送ログを一覧表示しています。参照する対象がほぼ固定の場合は一つ作っておけば大変便利です。これを普通にそれぞれ確認するとなると、複数画面を横断する必要があります。 作り方 先ずはダッシュボードの作成です。要件に応じて適当な単位で作りましょう。(サーバ毎、VPC毎、案件毎、など) 名前は適当につければよいです。 次に各種のメトリクスなどを追加していきます。 からの データ型はメトリクス、ログ、アラームと３種類あり、メトリクスは例で挙げた画像の左半分、ログは右下部分、アラームは右上部分に対応しています。 個々のグラフの作り方には触れませんが、やればわかると思います。各種色々なタイプがあるので試してみましょう。 注意：アラームは通知はされません。通知は別途、アラーム定義のアクションでSNSを定義するなどの必要があります。 ログウィジェットについて メトリクスとアラームは簡単なのですが、ログウィジェットについて触れておきます。 ログのウィジェットは以下のように、ロググループを選択し、CloudWatch Insightsのクエリで表示を絞ることができます。 (* ウィジェットタイプは”ログテーブル” を選択しましょう。) 上記は特定のロググループに対して”Error” 文字列を含むレコードのみを抽出しています。ダッシュボードに表示させたいレコードのみを抽出して表示させるのがよいでしょう。ダッシュボードはこうなります。 特に、ロググループに対してメトリクスフィルターでエラー検知をしている場合、アラートが発報してもどのレコードが探すのが大変というケースはあります。その場合はメトリクスフィルターと同等のクエリー定義を使ってダッシュボードに表示させれば異常レコードはすぐに判明するでしょう。 最後に EC2の、と書いてしまいましたが、EC2でなくともどのようなメトリクスも含めることができます。 環境内の主要な監視項目をまとめておけば、必要な情報にすぐにアクセスできるため、大変便利に感じました。 簡単に作成できますので、色々試されるとよろしいかと思います。
こんにちは。SCSKの松渕です。 今回は 2026年1月27日に発表 されたばかりのGeminiの超強力な新機能、 Agentic Vision について検証したのでブログ書いていきます！！ はじめに Agentic Visionとは 端的に言うと Gemini 3 の 拡張機能 です。（flashの機能と広く説明されてますが、proでも利用できました） Geminiが 自ら動的にコードを書いて 画像を能動的に『調査』する機能 です。 いままでのマルチモーダルAIでは、画像認識は静的なもの（一度見るだけ）でした。 この機能を活用すると、Geminiが Pythonコードを自動生成 し、特定の領域をクロップ（切り抜き）したり、ズームしたりといった 自律的にアクション をして、結果をさらに観測するというループを回すことができるようになります。 なお、 Googleがデモを公開 しているので、ぜひ一度体験してみてください！！ 主なユースケース 主なユースケースは以下のように考えられているようです。 1. 精密な検査とズーム Geminiに処理させたい内容次第では、画像は大きいが処理内容としては一部分だけ必要になることがあります その際、 必要な部分だけをズームする と精度が上がるため、Gemini自身が拡大の必要性を判断して実行します。 2. 正確なカウントとアノテーション 飲み会とかで人数カウントする際、10人超えてくるとぱっと見でわからなくなりますよね？ そういうとき、一人ひとりカウントしていくかと思います。 同様に、「数えた」という印を画像につけていくことで カウントを正確にする といったことも可能です。 3. アナログデータのデジタル資産化 アナログデータを画像認識し、そのまま Pythonでグラフ化して可視化 する、といった一連の処理が自律的に完結します。 また、Google検索等のグラウンディング機能を併用すれば、 画像から読み取ったデータと「世の中の最新トレンドや統計データ」を掛け合わせた分析レポートを自動作成 する、といった活用も可能になります。 設定方法 試し方としては大きく2つのやり方があります。 1. Google AI Studio で試す（最速30秒） まずは手元の画像で動かしてみたい、という方はこちらが一番早いです。 モデルの選択 : 右側の設定パネルで Gemini 3 Flash を選択します。 ツールの有効化 : 同じ設定パネル内にある 「Tools」 セクションを探し、 「Code Execution」 のチェックボックスをオンにします。 画像をアップロード : プロンプト入力欄に解析したい画像を貼り付けます。 依頼を投げる : 「画像内の〇〇を詳しく調べて」など、精密な調査が必要な指示を出します。 ズームが必要だとGeminiが判断すれば、勝手にPythonコードが走り、ズームされた画像（クロップ画像）が生成され始めます。 2. Vertex AI (Python SDK) で実装する Google Cloud環境でアプリに組み込む場合は、SDKからツールとして定義します。 Python SDKであれば、gemini API呼び出し時configに 以下一行追記するだけ です。 tools=[types.Tool(code_execution=types.ToolCodeExecution())] 簡単そう！と思って今回はVertex AI Studioでやってみることにしてみました。 が、意外にもちょっと面倒でした。。。 前準備 インプット画像準備 読み取りにくそうなpdfサンプル準備します。手書きの何かの申込書らしきものを作成してみました。 あえて反転 させております。 ※住所、カード番号、電話番号は架空のものです。 Agentic Vision無しで読み取り 失敗例が欲しく、一度Vertex AI Studioで普通に読み取り処理流します。 利用したプロンプトはこちら。システムプロンプトにもう少しちょこちょこ書きましたが割愛。 # 以下の項目を読み取ってください - ふりがな - 氏名 - 性別 - 所在地（郵便番号） - 所在地（住所） - 電話番号 - メールアドレス - 申し込みコース - サービス開始希望日 - 追加オプション ※複数申し込み可能 - お支払い方法 ※単一選択。丸印での選択 - 請求締日 ※「お支払い方法」で請求書払いを選択している場合のみ - カード名義 ※「お支払い方法」でクレジットカードを選択している場合のみ - クレジットカード種別 ※「お支払い方法」でクレジットカードを選択している場合のみ 単一選択 - カード番号 ※「お支払い方法」でクレジットカードを選択している場合のみ - カード有効期限 ※「お支払い方法」でクレジットカードを選択している場合のみ "XX年XX月" の形式で出力すること - 請求先名 ※「お支払い方法」で請求書払いを選択している場合のみ 出力結果は以下でした。 { "ふりがな": "まつぶち けんた", "氏名": "松渕 健太", "性別": "男", "所在地（郵便番号）": "012-3456", "所在地（住所）": "東京都千代田区千代田1-1-1", "電話番号": "090-1234-5678", "メールアドレス": "xxx@gmail.com", "申し込みコース": "A. プラン1", "サービス開始希望日": "2026年2月20日", "追加オプション": [ "追加サービスC" ], "お支払い方法": "1. クレジットカード", "請求締日": "", "カード名義": "Kenta Matsubuchi", "クレジットカード種別": "VISA", "カード番号": "123456789012", "カード有効期限": "26年12月", "請求先名": "", "請求先住所": "" } あれ。。 Agentic Vision無しで成功 しちゃった。。Gemini 3 flash 賢すぎないですか？ でもまぁ、突き進みます！！ 設定と実行 Vertex AI Studioでの実施試みるがNG Google Cloudの画面から、Vertex AI Studioの画面を開きます。 プロンプトを入れて、資料添付した状態にします。 右上の「コード」ボタンを押下。 以下の画面に遷移します。 「2.Use the following code in your application to request a model response」のところに1行入力するだけ！ と思ってたら、入力できませんでした。 APIキーの発行 ということで、 面倒ですがNotebookから実行 することにします。 先ほどの画面の上部の「ここですべてのAPIキーを表示するか、新しいAPIキーを作成できます」を押下。 設定画面へ遷移するので、「APIキーを作成」を押下。APIキーが作成されます。 「鍵を表示します」をクリックして APIキーをコピー しておきます。 → → 今回、検証には Google AI Studio で発行したAPIキーを使用しました。非常に便利な一方、 間違って公開等してしまった場合には、不正利用されて高額請求が来てしまう等のリスクがあります ！！ ソースコードへのべた書きし、そのままGitHubで公開してしまう等の事象はよく聞きますので、十分ご注意ください。 Vertex AI Studioの画面に再度戻り、「ノートブックを開く」を押下。 Colab EnterpriseのNotebookからの実行 ノートブック画面に遷移します。「YOUR_API_KEY」部分に先ほどコピーしたAPIキーを貼り付けて、まずは実行します。 正常に動きました。 次のセクションですが、 ノートブックを開く前から入力していたプロンプトがすでに反映された状態 かと思います。 そのため、generate_content_configの中に「 tools=[types.Tool(code_execution=types.ToolCodeExecution())], 」 の一行だけを追記して実行すればAgentic Visionは動作します！ ただし、私はブログ用に途中での思考や画像加工した出力も出すようにいろいろと変えたので、追記部分太字で記載します。 from google import genai ～～省略～～ text1 = types.Part.from_text(text="""# 以下の項目を読み取ってください。 読み取る上で、画像反転や拡大等必要であれば実施ください。 # 画像出力に関する重要ルール 画像を保存（imwriteなど）したら、必ずその直後に以下のコードを実行して、 画像データを標準出力に書き出してください。これがないと画像が見えません。 ～～省略～～ generate_content_config = types.GenerateContentConfig( temperature = 1, top_p = 0.95, max_output_tokens = 65535, ★★以下一行追加★★ tools=[types.Tool(code_execution=types.ToolCodeExecution())], ～～省略～～ for chunk in client.models.generate_content_stream( model = model, contents = contents, config = generate_content_config, ): for part in chunk.candidates[0].content.parts: # ★★ 以下、プロセスの出力のため追加★★ # 1. 思考プロセスの表示（青文字） if part.thought: print(f"\033[34m[Thinking]:\033[0m {part.text}") # 2. 実行したコードの表示（緑文字） elif part.executable_code: print(f"\n\033[32m[Action - Python Code]:\033[0m\n{part.executable_code.code}\n") # 3. 生成された「画像」をその場で表示！ elif part.code_execution_result: output = part.code_execution_result.output print(f"[Execution Output]: {output}") # ログとして表示 if output and "FILE_DATA:" in output: # AIが吐き出したbase64データを探す for line in output.split("\n"): if line.startswith("FILE_DATA:"): _, filename, b64data = line.split(":", 2) # ローカルに保存 with open(f"debug_{filename}", "wb") as f: f.write(base64.b64decode(b64data)) print(f"\n★画像を保存しました: debug_{filename}") # Colabなら表示 display(Image(f"debug_{filename}")) # ★★ここまでプロセスの出力のため追加★★ # 4. 最終回答 elif part.text: print(part.text, end="") generate() 結果確認 実行結果 [Thinking]: **Contemplating Image Processing** I've been working on extracting data from a scanned form. Right now, I'm focusing on the initial image processing steps. I've realized the image needs a 180-degree rotation . After that, I will attempt to identify and segment the various fields within the document, such as the provided "ふ" field. ～～省略～～ [Action - Python Code]: import cv2 import numpy as np # Load the image img = cv2.imread('input_file_0.png') # Rotate the image 180 degrees rotated_img = cv2.rotate(img, cv2.ROTATE_180) cv2.imwrite('rotated_form.png', rotated_img) ～～省略～～ ★画像を保存しました: debug_top.png ★画像を保存しました: debug_middle.png ★画像を保存しました: debug_bottom.png ★画像を保存しました: debug_rotated_form.png [Thinking]: **Examining the Fields** I'm now able to see the images with much greater clarity. This has led me to re-examine the identified fields. Right now, I'm taking a close look at the details within them, such as `ふりがな`, `氏名`, `性別`, and `所在地（郵便番号）`. The circled "男" for gender is particularly helpful. ～～省略～～ 黄色マーカー部分だけ読んでもらえればと思いますが、 最初に180度回転させる必要があると判断 して 自律的にアクション しているのが見て取れます。ローテーションだけでなく3分割した画像も作っておりますね。 最後に、 クリアに見れるようになったと自分でコメント してます！！ なお、出力されたファイル群は以下の通り。 反転が戻った画像 と、 1/3ずつに拡大した画像 が中間ファイルとして作成されておりました。 もちろん最終的な出力JSONは、 すべて正しく読み取れておりました。 Agentic Vision使う前から読み取れていたので当然ですが。。。 まとめ 今回は、Googleの最新機能である Agentic Vision を使い、手書きの反転画像をJSON化する検証を行いました。 特に印象的だったのは、Geminiが自ら「画像が逆さまだから180度回転させよう」「文字が小さいから3分割して拡大しよう」と 判断し、Pythonコードを生成・実行 したプロセスです。これまでの「ただ画像を見るだけ」のAIとは一線を画す、まさ に 「意思を持った調査員」のような挙動でした。 また、本来の目的とは違いますが、 Gemini 3 flashがそもそも画像認識能力が非常に高い と感じました。 破線〇への○付きや、かすれたチェックボックスをすべて一発で正確に読み取る とは思っていなかったので、その点も非常に驚きでした。 画像解析の「精度」の壁に悩んでいた方は、ぜひ一度このAgentic Visionを試してみてください。きっと、AIが「自分で虫眼鏡を取り出す」瞬間に驚くはずです！
SCSKでは、Dropbox導入案件の多くで、オンプレファイルサーバやNASなどからDropboxにデータ移行のお手伝いをさせていただいております。近年、弊社がデータ移行する際はDropbox社が推奨するMovebotというデータ移行ツールを利用することがほとんどです。 しかし、実は別記事(「 【決定版】Dropboxへのデータ移行を自力で効率化！SCSK「セルフデータ移行ツール」忖度なしレビュー 」)でも紹介しているように、弊社ではDropbox APIを使ったセルフ データ移行ツール を開発しています。 そこで、今回は、Dropbox APIによるデータ移行方法、移行で利用するAPIの説明や開発時に苦労した点などをご紹介したいと思います。 ちょっと脱線 – Dropboxへのデータ移行方法 本題に入る前に、少しDropboxへのデータ移行方法についてお話したいと思います。 筆者が初めてDropboxへのデータ移行案件に関わった2018年頃の話です。 まだDropboxへのデータ移行ツールが存在せず(という記憶があります)、Dropboxデスクトップクライアントのデータ同期機能を使って移行するしか方法がありませんでした。ただ、この方法にはいくつか大きな課題がありました。 Dropboxデスクトップクライアントでのデータ移行って大変なんです Dropboxデスクトップクライアントを使ったデータ移行については、以前のブログ記事「 Dropboxへのデータ移行ってどうやるの？ 」に詳しいことをご紹介していますので、そちらを見てください。 課題をまとめると次の3点です PCのローカルストレージ容量問題です Dropboxデスクトップクライアントの最大同期数の問題です データ同期の結果を確認することができないことです このように、Dropboxデスクトップクライアントを使ったデータ移行は、PCストレージ容量と同期ファイルサイズに大きく影響され、100GB以下の小規模なデータ移行までが限界という感じです。Dropbox導入企業様自身でデータ移行するには良い方法かもしれませんが、ファイルサーバのような大規模データ移行には向いてません。 Movebotは… 冒頭でお話したとおり、近年弊社ではDropbox導入案件のデータ移行作業において、Movebotを受かってデータ移行を行っています。その主な理由は、下記の3点です。 Movebotは、データ移行に用いるPCのローカルストレージを利用しないこと (ストレージ容量の影響を受けない) WEB画面からリモート操作が できること データ移行ログが充実していること 特に、1. のPCローカルストレージの容量に影響しない仕組みのため、大容量のデータ移行に向いたツールです。 ただ、Movebotにもデメリットはあります。Movebotはデータ転送容量課金ですので、データ移行容量によってはデータ移行コストが高くなってしまいがちです。データ移行作業に回せる予算が少ないと、Movebotの採用は難しい場合も…。 Movebotについては、別のブログ記事で詳しくご紹介していますので、そちらもご覧ください。 「 Dropboxへのデータ移行ってどうやるの？ 」 「 Movebot×Dropbox！データ移行ツールMovebot 」 Dropbox APIによるデータ移行ツール! Movebotのように、PCストレージ容量に影響を受けないようにするには、ファイルサーバから読み取ったデータを直接Dropboxにアップロードする必要があります。これを実現するのが、Dropbox社が公開しているDropbox APIです。 Dropbox APIにはたくさんの機能エンドポイントが用意されていますが、その中にファイルアップロードするためのAPIも含まれています。これを使ったデータ移行ツールを開発し、お客様自身で比較的簡単にデータ移行できるようなにツールを提供できれば、喜んでいただけるのではないか。そうして開発したのが sxtool です (GUI付き版が 「セルフデータ移行ツール」となります) 。弊社自身、気楽に使えるデータ移行ツールが必要だったというのも理由の一つですが…。 それでは、Dropbox APIを使ったデータ移行処理について詳しくご紹介したいと思います。 「 SCSKにてDropbox APIで作成したツールを紹介します 」 【決定版】Dropboxへのデータ移行を自力で効率化！SCSK「セルフデータ移行ツール」忖度なしレビュー 」 Dropbox APIを使ったデータ移行処理 データ移行処理って？ ファイルサーバのデータをDropboxに移行するには、下記のようにファイルサーバからファイルのデータを読み込み、Dropbox APIを使ってDropboxに書き込むことで実現できます。 図1: データ移行ロジック ファイルサーバのファイル読み込みは、開発言語に用意されているファイルI/Oのライブラリ(関数)を利用すれば簡単に実装できます。Python だと、下記のようにopen関数やread関数を使います。 with open(path, 'rb') as f: # path変数で指定したパスのファイルを開く data = f.read() # データ読み込み処理 Dropbox へのファイルアップロード Dropboxに読み込んだファイルデータを書き込む(アップロード)には、Dropbox APIの upload エンドポイントを使用します。下図は、Dropbox開発向けサイトの upload エンドポイントのマニュアルを抜粋したものです。(出典: HTTP – Developers – Dropbox ) 図2: uploadエンドポイントマニュアル(抜粋) 上記マニュアルに記載されてるように、upload エンドポイントは、Dropbopxでのファイルパスや書込みモードなど、いくつかのパラメータと(読み込んでおいた)ファイルのバイナリデータを指定し、Dropboxにアップロードします。 upload エンドポイントのパラメータ: path: ファイルパス mode: 書込みモード (追加(add) / 上書き(overwrite) / 更新(update)) autorename: 自動でファイル名を変える (上書きせず、番号をつける) mute: 通知をする/しない client_modified: 移行元のファイルタイムスタンプを指定 (更新タイムスタンを保持できる) など pythonでDropboxにファイルアップロードする処理を実装すると、下記のようになります。 with open(path, 'rb') as f: # path変数で指定したパスのファイルを開く data = f.read() # 移行元のデータを読み込み url = 'https://content.dropboxapi.com/2/files/upload' param = { # upload エンドポイントのパラメータを指定 "path": path, "mode": mode, "autorename": False, "client_modified": source_file_timestamp, "mute": False, "strict_conflict": False } headers = { "Authorization": "Bearer " + oauth_token, "Content-Type": "application/octet-stream", "Dropbox-API-Arg": json.dumps(param), } response = requests.post(url, headers=headers, data=data) # APIコール このコードを実際に動かすには、Dropboxの認証情報である OAUTH_TOKEN を事前に取得し、”oauth_token” 変数に代入するか、oauth_token 部分を OAUTH_TOKEN文字列に置き換える必要があります。 また、他にも、uploadエンドポイントの結果確認処理や例外処理など実現すべき点はたくさんあります。 フォルダ単位のデータ移行 1ファイルのみアップロードする処理は、先程ご紹介したとおりです。この処理を移行元フォルダ配下の全ファイル分繰り返し実施すれば、フォルダ単位の「データ移行」が実現できます。移行元フォルダにサブフォルダが存在した場合、サブフォルダの作成処理とサブフォルダの移行処理(フォルダ単位の移行処理を再帰的に呼び出す)を実施します。 これをチャートにすると、ざっくり下図のようになります。 図3: データ移行ロジック2 この仕組みでデータ移行すると、1ファイルずつファイルサーバから読み込んでは、Dropboxにアップロードすることになります。要は、シーケンシャルに1ファイルずつしか移行できないわけです。 例えば、1MBのファイルを1つアップロードするのに、0.2 秒掛かると仮定すると、1MB x 1万ファイルのデータ移行に 約 33 分掛かります。 式) 0.2 秒 x 10,000 = 2,000 秒 ≒ 33分 このときのデータ転送速度は 5MB/sec です。 式) 1MB x 10,000 ÷ 2,000 秒 = 5 MB/sec ネットワーク帯域が 1Gbps (=125MB/sec) の回線だと仮定すると、データ移行ではネットワーク帯域を少ししか使っていないことになりますね。ネットワーク帯域の1Gbpsという数値は理論値なので 実際には理論値の 5～6割程度が利用可能な帯域だとしても、帯域の 1/10 くらいしか使っていませんね。ネットワーク帯域をすべて使い切ってしまうと他の業務に影響がでるため好ましくありませんが、業務に影響が出ない範囲でデータ移行が利用する帯域を増やして、移行時間を短縮する必要があります。 データ移行の並列化 さて、ネットワーク帯域をもっと有効活用するにはどうすればいいでしょうか？ そうです、Dropboxサーバへのファイルアップロード処理を何個も同時実行すればいいのです。 例えば、４ファイル同時にアップロードできれば、5MB/sec x 4 = 20 MB/sec の帯域を使いますが、4ファイル順番に移行するよりも単純計算で移行時間が 1/4 になります。1万ファイルの移行時間もたったの 8分ちょっとに短縮できちゃいます。ファイルアップロードの並列化は移行時間の短縮にとても効果がありそうです。 APIコール数の削減 また、APIコール数の削減も移行時間の短縮に効果があります。 Dropbox APIの処理時間は「リクエスト送信 +サーバでの処理+レスポンス受信」の合計となります。例えば リクエスト送信 0.2秒、サーバサイド処理 0.3 秒、レスポンス受信 0.2 秒 と仮定すると、1 APIコールの処理時間の合計が 0.7 秒。「リクエスト送信」と「レスポンス受信」で 0.4 秒。「サーバサイド処理」が 0.3 秒 ですので、「リクエスト送信とレスポンス受信」の処理時間のほうが「サーバサイトの処理」よりも長くなってしまっていますね。 Dropboxのデータ移行先サブフォルダを作成する場面で計算してみましょう。 移行元には500個のサブフォルダが存在するとします。1サブフォルダずつフォルダ作成を行うとすると、create_folder エンドポイントを 500 回コールすることになります。これだけで、350秒 (約 6 分) もかかっちゃいます。 式) 500 x 0.7 秒 = 350 秒 (約 6 分) 1回のサブフォルダ作成リクエストで複数のサブフォルダをまとめて作成できると、 APIコール数を削減できますね。1リクエストで 500個作成できるとすると、499 x 0.4秒(リクエスト+レスポンスの時間) ≒ 200秒 (約 3.5分) の短縮になります。 データアップロードの並列化とAPIコール数を削減するAPI Dropbox APIには、「ファイルアップロード処理の並列化」と「APIコール数の削減」ができるエンドポイントも用意されています。それが create_folder_batch エンドポイントと upload_session エンドポイント群です。 まとめてフォルダ作成エンドポイント create_folder_batch と create_folder_batch/check create_folder_batch エンドポイントを利用すると、Dropboxサーバに複数のフォルダ作成を依頼できます。最大 1000フォルダ分を1リクエストのパラメータに指定できます。サーバサイドの処理が非同期処理になった場合は、終了待ちを行う create_folder_batch/checkエンドポイントで処理完了の待ち合わせを行うことが可能です。 ファイルアップロード並列化エンドポイント upload_session/start Dropboxサーバにファイルデータ送信のセッションを作成するためのエンドポイント。 このエンドポイントと次の append エンドポイントを利用して、ファイルデータ送信を行います。 ファイルアップロード処理の完了は、upload_session/finish エンドポイントを使います。 upload_session/append upload_sessoin/start で作成したファイルデータ送信用セッションを使って、ファイルデータをアップロードできます。何度も append エンドポイントを繰り返し利用することで、大きなファイルをアップロードすることも可能です。 ファイルメタデータまとめてエンドポイント upload_session/finish_batch upload_session/start および append エンドポイントで送信したファイルデータに対して、メタデータ(ファイル名や更新時間など、ファイル情報と呼ばれるもの)をつけてDropboxサーバに保存するためのエンドポイントです。 upload_session/finish エンドポイントでは 1ファイル分のメタデータを書込みできますが、upload_session/finish_batch エンドポイントを利用すれば 最大 1000ファイル分のメタデータを書込むことができ、APIコール数の削減が可能です。 upload_session/finish_batch/check upload_session/finish_batchで多くのファイルメタデータを書き込もうとした場合、非同期処理になる場合があります。この場合、finish_batch/checkエンドポイントを使って、finish_batchエンドポイントの終了確認を行う必要があります。 弊社が開発したデータ移行ツールでは、これらのエンドポイントを駆使して、データ移行時間の短縮を図っています。データ移行のロジックも図4のようにサブフォルダの作成処理、ファイルアップロード処理に分割し、おまとめエンドポイントの利用と並列化を実現しやすいように変えています。 図4: 改良版データ移行ロジック これにより、サブフォルダの作成をまとめることができ、最大1000個のサブフォルダを1回のAPIコールで済ますことができます。サーバサイドの処理時間は変わらないとしても、リクエスト送信+レスポンス受信 の時間 1,000回分を 1回分 だけに削減できます。 また、ファイルアップロード処理は、upload_session/start + upload_session/append を用い、並列してファイルデータをアップロードすることでデータ移行時間を短縮します。 upload_sessionエンドポイントのもうひとつのメリット upload_sessionエンドポイントを利用する、メリットがもうひとつあります。 uploadエンドポイントでは、最大 150MB までしかアップロードできないという制限があります。ということは、150MBより大きなファイルはDropboxにアップロードできないということになってしまうのですが、その制限をクリアするのが upload_session エンドポイントなのです。 upload_session/start や upload_sessoin/append も 1コールで指定できるファイルデータサイズは最大 150MB と upload エンドポイントと変わりないのですが、元のファイルを 150MB単位でブロック化し、upload_session/append エンドポイントで追加ブロック分を繰り返し送信することで、最大 2TB までアップロードできるようになっています。 エンドポイント アップロードできるファイルサイズ upload 最大 150MB upload_session/* 最大 2 TB ファイルサイズが 150MB 以下だと、upload_session/start と append, finish の 3つのエンドポイントを使ってファイルアップロードすることになるため、uploadエンドポイントより不利な面がありますが、finish_batch を使えばAPIコール数の削減も実現できますし、大きなファイルを送信できるという点で upload_session 系エンドポイントを利用する価値があります。 upload_sessoin系エンドポイントのサンプルコード upload_sessionエンドポイントを使った簡単なサンプルコードを紹介します。 まずは、ファイルデータの送信部分です。 下記のサンプルコードは、1ファイル分のファイルデータをアップロードする処理です。upload_session/start ではファイルデータを添付せず、ファイルデータのアップロードはすべて upload_sessoin/append で行っています。 with open(source_path, 'rb') as f: offset = 0 if <移行元ファイルサイズ> == 0: flag_close = True else: flag_close = False # upload session開始 url = "https://content.dropboxapi.com/2/files/upload_session/start" param = { "close": flag_close } headers = { "Authorization": "Bearer " + oauth_token, "Content-Type": "application/octet-stream", "Dropbox-API-Arg": json.dumps(param), } response = requests.post(url, headers=headers, data="") # APIコール response_json = response.json() session_id = response_json["session_id"] # ファイルデータは upload_session/append で送信 while True: chunk = f.read(UPLOAD_CHUNK_SIZE) # UPLOAD_CHUNK_SIZE は 150MB if len(chunk) > 0: if len(chunk) < UPLOAD_CHUNK_SIZE: # 詠み込んだ量が 150MB 以下ならこの append で終わり flag_close = True else: flag_close = False url = "https://content.dropboxapi.com/2/files/upload_session/append_v2" param = { "cursor": { "session_id": session_id, "offset": offset }, "close": flag_close } headers = { "Authorization": "Bearer " + oauth_token, "Dropbox-API-Arg": json.dumps(param), "Content-Type": "application/octet-stream", } response = requests.post(url, headers=headers, data=chunk) # APIコール offset += len(chunk) この処理を並列実行できるように関数化し、ファイル単位でプロセスを分けることで並列実行を実現します。 ファイルメタデータの書込み処理は、上記のファイルデータのアップロードセッション 1,000個分をまとめて finish_batch を使うため、ファイルデータアップロード部分と分離しておきます。 upload_session/finish_batch を使ったメタデータ書込み処理 entries = [] # session_ids = データアップロードのセッションIDリスト for session_id in session_ids: entry = { "cursor": { "session_id": session_id, # ファイルアップロード時の session_id (session_ids リストで保存しておく) "offset": offset # ファイルアップロード時の offset値 (session_ids リストで保存しておく) }, "commit": { "path": target_path, # session_ids リストで保存しておいた移行先パス "mode": mode, "autorename": False, "client_modified": client_modified, # session_ids リストで保存しておいた移行元ファイルタイムスタンプ "mute": False, "strict_conflict": False } } entries.append(entry) # APIコール部分 url = "https://api.dropboxapi.com/2/files/upload_session/finish_batch_v2" headers = { "Authorization": "Bearer " + oauth_token, "Content-Type": "application/json", } data = { "entries": entries } response = requests.post(url, headers=headers, data=data) # APIコール # このあと # finish_batch がバックグランドジョブになった場合は、upload_session/finish_batch/check で定期的に終了確認を行う おわりに 今回は前編ということで、データ移行に関係する Dropbox API の紹介と弊社が開発したデータ移行ツールの処理ロジック、サンプルコードをご紹介を致しました。 後編では、並列化の効果や他の機能や工夫点などをご紹介する予定にしています。 SCSKでは、お客様のご要件に合わせたDropbox APIツールの開発も行っております。Dropbox運用の効率化や棚卸しなどでツールがほしい！といったご要望があれば、是非 SCSKまでご遠絡頂けたらと思います。 問合せ先: dropbox-sales@scsk.jp 弊社Dropbox紹介ページ: https://www.scsk.jp/product/common/dropbox/index.html
こんにちは！SCSKの三浦です。 ServiceNowの運用業務を行う中で、少しずつ知識がついてきました。 今回は、ServiceNowの数多くあるモジュールの中から「サービスポータル」、「要求アイテム」、 「アイテムデザイナー」、「アイテムの管理」をご紹介します。 ①サービスポータル（Service Portal） サービスポータルは、利用者が申請や問い合わせを行う場所です。 パスワードリセット PCやソフトウェアの申請 問い合わせ登録 FAQの参照 などを行うことができます。 管理者向けの画面ではなく、エンドユーザー向けの窓口サイトという位置づけです。 実際に名刺作成申請をしてみます。 使用したいカタログアイテムをクリックすると、申請フォームに入力することができます。 申請が完了しました！ ②要求アイテム（Requested Items） 要求アイテムは、ユーザーが申請した内容を1件ずつ管理するためのモジュールです。 サービスポータルのカタログから申請が行われると、その申請内容が「要求アイテム」として登録されます。 先ほどサービスポータルから申請した名刺作成が、要求アイテムに１件のレコードとして登録されていますね。 ここでは、 申請内容の確認 ステータスの管理 担当グループの割り当て 作業状況の確認 などを行います。 ↑要求の処理状態や申請内容を見ることができます つまり要求アイテムとは、サービスポータルからエンドユーザーが送った要求を、技術者が管理するモジュールです。 ③アイテムデザイナー（Item Designer） 次にカタログアイテムを作成するモジュールをご紹介します。 アイテムデザイナーは、カタログアイテムのフォーム内容を作成するモジュールです。 関連リンクから申請フォームの質問項目を追加したり、必須設定や表示・非表示設定を行ったりすることができます。 プログラミングを行わなくても画面操作で設定できるなんて便利だなぁ ④アイテムの管理（Maintain Items） アイテムの管理はカタログアイテムそのものを管理するモジュールです。 ここでは カタログアイテムの作成 変数(申請フォームの質問項目)やスクリプトの設定→表示順序等 ワークフローやフローとの紐づけ カタログアイテムの公開・非公開の設定 などを行います。 アイテムデザイナーがカタログアイテムの入力フォームを作る場所とすると、アイテムの管理はカタログアイテム全体の設定を行う場所です。 まとめ 今回、「サービスポータル」、「要求アイテム」、「アイテムデザイナー」、「アイテムの管理」の4つをご紹介しました。いずれもサービスカタログに関係するモジュールです。それぞれの役割を整理すると以下のようになります。 サービスポータル：エンドユーザーが使う申請・問い合わせ画面 要求アイテム：申請された内容を管理する アイテムデザイナー：カタログアイテムの申請フォームを作成する アイテムの管理：カタログアイテム自体を管理する モジュール名だけでは、その機能や役割の違いが分かりにくいと感じる方も多いと思います。 この記事を通じて少しでも理解が深まり、お役に立てれば嬉しいです。 ここまで読んでくださり、ありがとうございました！
こんにちは、SCSK株式会社の中野です。 本記事ではZabbix 7.0.xからZabbix 7.4.xの最新バージョンへアップグレードする手順について説明します。 新しい機能などをお試しいただきたい方など、最新バージョンへバージョンアップしてみてはいかがでしょうか。 今回の構成は以下とさせていただきます。 OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 9 DATABASE: MySQL WEB SERVER: Apache Zabbix7.4の新機能（抜粋） Zabbix 7.4における、主な主な新機能は以下となります。 ・TimescaleDB、MySQL、PostgreSQL、MariaDBの最大サポートバージョンが定期的に拡張 ・Zabbix agent MSIインストーラーに多数のコマンドラインパラメータオプションを追加 ・RedisプラグインにTLS対応およびTLS起動時検証機能を新規搭載 ・OracleプラグインでTNS名サポートおよび追加ロール対応を実装 ・SNMPv3認証情報の自動リロードとsmart.disk.discoveryアイテムにtypeパラメータ追加 Zabbix 7.0から 7.4へバージョンアップ まずはZabbixプロセスを停止させます。 systemctl stop zabbix-server エージェント、エージェント2もアップグレードする場合は、同様に停止します。 systemctl stop zabbix-agent2 ※バージョンアップ時の想定外の事象によるデータ損失を防ぐため、必要に応じてDBのバックアップを実施ください。 本記事ではZabbix設定ファイル、および関連ファイルのみバックアップを取得します。 mkdir /opt/zabbix-backup/ ※設定ファイル cp /etc/zabbix/zabbix_server.conf /opt/zabbix-backup/ cp /etc/httpd/conf.d/zabbix.conf /opt/zabbix-backup/ ※PHPファイルとZabbixバイナリ設定 cp -R /usr/share/zabbix/ /opt/zabbix-backup/ cp -R /usr/share/zabbix-* /opt/zabbix-backup/ リポジトリパッケージを最新バージョンに更新する。 rpm -Uvh https://repo.zabbix.com/zabbix/7.4/release/rhel/9/noarch/zabbix-release-latest.el9.noarch.rpm Zabbixコンポーネントのアップグレードする。 dnf clean all dnf install zabbix-server-mysql zabbix-web-mysql zabbix-agent2 zabbix-agent2-plugin-* ※Zabbixコンポーネントをアップグレード後にWebフロントエンドをアップグレードする dnf install zabbix-apache-conf systemctl restart httpd Zabbixプロセスを起動させる。 systemctl start zabbix-server systemctl start zabbix-agent2 ログを確認して、「database upgrade fully completed」が出力されていることを確認する。 tail /var/log/zabbix/zabbix_server.log -n 1000 15109:20260202:083721.036 completed 97% of database upgrade 15109:20260202:083721.041 completed 98% of database upgrade 15109:20260202:083721.046 completed 100% of database upgrade 15109:20260202:083721.050 database upgrade fully completed バージョンアップ作業は完了です。 最後に バージョンアップ作業は比較的簡単に実施することはできます。 ただ既存バージョンとの異なる点や、バージョンアップ時の注意点が上記の手順以外で環境ごとに発生する可能性がございます。 そのため、バージョンアップを実施する際は、検証環境等で十分に検証したうえで実施いただければと思います。 以上、最後まで読んでいただき、ありがとうございました！！
こんにちは、SCSK株式会社の中野です。 Zabbixのダウンロードページを見ると最新バージョンであるZabbix 8.0のPRE-RELEASE版がリリースされておりましたので、 早速インストールしてみたいと思います。 今回は、AWS環境上にRHEL10.1を立てて、その中にZabbixをインストールしてみました。 Zabbixとは まずはZabbixの説明を簡単にさせていただきます。 Zabbixは、エンタープライズ対応のオープンソース統合監視ツールです。 サービスやそれを支える ITシステム(サーバ、ネットワーク機器等)の状態を把握し、障害の予兆やサービスへ影響を及ぼす事象が発生した際に、システム管理者やオペレータに通知を行うオープンソースの統合監視ソリューションです。 数万デバイス規模のエンタープライズ環境でも多数の稼動実績を誇っています。 Zabbixの詳細情報については、下記リンクよりご確認ください。 Zabbix :: The Enterprise-Class Open Source Network Monitoring Solution ZabbixはITインフラストラクチャ・コンポーネントの可用性やパフォーマンスを監視するためのエンタープライス向けソフトウェアです。Zabbixはオープンソース・ソフトウェアとして開発されており、無料でダウンロードいただくことが可能です。 www.zabbix.com 導入手順 早速、Zabbix8.0 PRE-RELEASE版を導入していきたいと思います。今回の構成は以下とさせていただきます。 ZABBIX VERSION: 8.0 PRE-RELEASE OS DISTRIBUTION: Red Hat Enterprise Linux OS VERSION: 10 DATABASE: MariaDB WEB SERVER: Apache Firewalld: 無効 関連パッケージのインストール、DB初期設定 Zabbixをインストールする前に、MySQLとApacheをインストールしておきます。 # 関連パッケージのインストール dnf install mariadb-server httpd # データベースを起動 systemctl start mariadb systemctl enable mariadb 続いて、Zabbix用データベースを作成します。 DB名、アカウント名やパスワード環境に応じて設定いただければと思います。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） # DB、アカウントを作成 > create database zabbix character set utf8mb4 collate utf8mb4_bin; > create user zabbix@localhost identified by 'password'; > grant all privileges on zabbix.* to zabbix@localhost; > set global log_bin_trust_function_creators = 1; > exit Zabbixサーバのインストール Zabbixをインストールする前に、専用のリポジトリを追加します。 # 専用リポジトリのインストール rpm -Uvh https://repo.zabbix.com/zabbix/8.0/release/rhel/10/noarch/zabbix-release-latest-8.0.el10.noarch.rpm # キャッシュのクリア dnf clean all # Zabbixサーバのインストール dnf install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-apache-conf zabbix-sql-scripts zabbix-agent zabbix-selinux-policy 続いて、Zabbix用データベースへ初期データをインポートします。 # DBへ初期データをインポート zcat /usr/share/zabbix/sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4 -uzabbix -p zabbix Enter password: （MySQLのzabbixアカウントのパスワードを入力） 初期データのインポート後、log_bin_trust_function_creatorsを無効にします。 # DBへの接続 mysql -uroot -p Enter password: （MySQLのrootアカウントのパスワードを入力） > SET global log_bin_trust_function_creators = 0; > exit その後、Zabbixサーバーの設定と起動を行います。 # 各パラメータ設定 /etc/zabbix/zabbix_server.conf DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=zabbix # サービスの起動 systemctl start zabbix-server zabbix-agent httpd php-fpm systemctl enable zabbix-server zabbix-agent zabbix-agent httpd php-fpm Zabbix WEBコンソールへのアクセス Zabbixのインストールは完了しましたので、Webコンソール上でセットアップしていきます。 ブラウザを立ち上げて、以下にアクセスします。 http://xxx.xxx.xxx.xxx/zabbix xxxには、今回構築したIPアドレスを入れてください。例えば、もしZabbixサーバーのIPアドレスが192.168.0.1なら、アドレスバーには”http://192.168.0.1/zabbix”と入力します。 言語を【日本語（ja_JP）】に変更して、【次のステップ】をクリックします。 すべての項目が「OK」になっていることを確認し、【次のステップ】をクリックします。 パスワード欄に先ほど設定したZabbixDBのパスワードを入力し、【次のステップ】をクリックします。 タイムゾーン欄で【(UTC+9:00) Asia/Tokyo】を選択、Zabbixサーバ名を記入し、【次のステップ】をクリックします。 設定内容に問題がなければ、【次のステップ】をクリックします。 【終了】をクリックすると、以下のようなログイン画面が表示されます。 初期状態でユーザーが登録されているので、以下のユーザー名・パスワードでログインします。 ユーザ名：Admin パスワード：zabbix ログインすると、WEBコンソール画面が表示されます。 以上でZabbixのインストールは完了です。 最後に Zabbix 8.0 PRE-RELEASE版は以前のバージョンと比較的に変わりなく、インストールすることができました。 今回はインストールのみでしたが、新機能も試してみて情報を発信していきたいと思います。 最後まで読んでいただき、ありがとうございました。
LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 システムのリプレースやハードウェア更新のタイミングで訪れる、「ミドルウェアのバージョンアップ」。 「サポート切れ（EOS）対応」や「魅力的な新機能の追加」など、OSのパッチ適用とはまた違った、期待と緊張が入り混じる一大イベントではないでしょうか。 しかし、HAクラスターソフトウェアであるLifeKeeperにおいて、この「バージョンアップ」は単なるファイルの置き換えではありません。 「インストーラーを実行して、バージョン番号が上がれば完了！」 ……そう思い込んで作業を進めた結果、再起動後に設定ファイルが初期値に戻っていたり、長年動いていたスクリプトが突然エラーを吐き始めたりといった、予期せぬトラブルに直面することがあります。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、サポートセンターに蓄積された「生のトラブル事例」を元に、安定運用のための実践的な知恵を共有していきます。 はじめに：成功へのロードマップを描く 連載第2回となる今回は、LifeKeeper本体やDataKeeperのバージョンアップに焦点を当てます。 バージョンアップ作業において、最も怖いのは 「見えない変化」 です。 インストーラーは便利ですが、それが裏側でどの設定を引き継ぎ、どの設定をリセットするのか、また新しいバージョンが古い設定をどう解釈するのかは、リリースノートの細部を読み込まない限り見えてきません。 今回は、実際にサポートへ寄せられた「バージョンアップ失敗事例」を以下の3つの「落とし穴（Trap）」に分類しました。 設定と環境の「サイレント変化」 過去の「まあいいか」が牙をむく 近道は「急がば回れ」 これらの事例から「なぜ失敗したのか」を学び、確実に成功させるためのチェックポイント（ロードマップ）を解説します。 その他の連載企画は以下のリンクからどうぞ！ 【リソース起動・フェイルオーバー失敗の深層 #1】EC2リソースが起動しない！クラウド連携の盲点とデバッグ術 – TechHarmony 【リソース起動・フェイルオーバー失敗の深層 #2】ファイルシステムの思わぬ落とし穴：エラーコードから原因を読み解く – TechHarmony 【リソース起動・フェイルオーバー失敗の深層 #3】設定ミス・通信障害・バージョン違いの深層と再発防止策 – TechHarmony 【OS・LKバージョンアップで泣かないために #1】OSバージョンは変えていないのに！？カーネル更新の「落とし穴」と互換性の真実 – TechHarmony 【実録】LifeKeeperバージョンアップの「困った！」事例ファイル ここからは、実際のサポート問い合わせをベースにしたケーススタディです。 「自分の環境でも起こりうるかもしれない」 という視点でご覧ください。 Trap 1：設定と環境の「サイレント変化」 バージョンアップによって、今まで使っていた設定や環境が 「静かに」 変わってしまう ケースです。 ■ケースA：アップデートしたら設定が消えた！？（Linux版） 「v9.5.2からv9.9.1へアップデートしました。エラーなく完了したのですが、再起動後になぜかプロキシ設定などが効かなくなっています…」 発生状況: アップデート作業自体は成功したものの、LifeKeeperの動作設定ファイル（ /etc/default/LifeKeeper ）に記述していたカスタム設定が消失していました。 原因: LifeKeeperの仕様により、更新インストール時に 一部の設定ファイルがデフォルト値に戻る（上書きされる） 挙動となっていました。 教訓: 「設定はすべて自動的に引き継がれるはず」という思い込みは危険です。特にメジャーバージョンをまたぐ更新では、バックアップと復元手順が必須です。 ■ケースB：スクリプトが動かない！Perlの罠（Windows版） 「v8.9からv8.10.2へ上げようとしています。パラメータ変更は不要と聞きましたが、本当にそのまま上げて大丈夫でしょうか？」 リスク: 調査の結果、LifeKeeperに同梱されているPerlのバージョンが、v8.10.1以降で「5.8系」から「5.32系」へと一気にアップグレードされていることが判明しました。 教訓: GenericリソースなどでPerlスクリプトを使用している場合、言語仕様の変更によりスクリプトが動作しなくなる可能性があります。アプリケーションだけでなく、ミドルウェアが依存する 「言語環境」の変化 も重要なチェックポイントです。 Trap 2：過去の「まあいいか」が牙をむく 古いバージョンでは許容されていた（あるいは無視されていた）設定の不備が、新しいバージョンの「厳格なチェック」によってエラーとして顕在化するケースです。 ■ケースC：亡霊IPがアラートを引き起こす 「OSとLifeKeeperを更新した後、ログに failed quickCheck due to ALRM signal というエラーが多発するようになりました。以前は出ていなかったのですが…」 原因: IPリソースの監視リスト（ pinglist ）に、既に撤去済みで疎通できない古いIPアドレスが残っていました。 なぜ今？: バージョンアップに伴い チェック処理やリトライの挙動が変化（厳格化） し、古いIPへの応答待ちが積み重なった結果、タイムアウト（ALRM signal）が発生していました。 教訓: 「今は使っていないけど残っている設定」は、バージョンアップ時の最大の敵です。更新作業はゴミ掃除の絶好の機会と捉えましょう。 ■ケースD：ディスクに名前がない！？（UUID問題） 「バージョンアップ後、DataKeeperリソースで『一意の識別子がない』という警告が出たり、パーティション情報が正しく取得できなくなりました」 原因: LifeKeeper/DataKeeperの新しいバージョンでは、ディスクを一意に特定するために 「UUID」の使用が必須化（または厳格化） されました。古い環境で「MBR形式」のパーティションを使っていたため、UUIDを持たず、新しいバージョンの要件を満たせなくなっていました。 教訓: ソフトウェアの進化に合わせて、インフラ側（パーティションテーブル等）もGPT形式へのモダン化が必要になることがあります。 Trap 3：近道は「急がば回れ」 手順を省略したり、無理なアップデートパスを通ろうとして失敗するケースです。 ■ケースE：飛ばしすぎたバージョンアップ 「v9.6.xからv9.8.1へ一気にアップデートしようとしたら失敗しました。2世代前からの更新はサポートされているはずですが…」 原因: 基本的には直接アップデートが可能ですが、 この特定のバージョン（v9.8.1）においては 内部パッケージの大幅な構成変更 があったため、例外的にv9.7やv9.8.0を経由する「ステップアップグレード」が必要でした。 教訓: 「いつものルール（N-2までOKなど）が今回も適用される」とは限りません。リリースノートには必ず 「アップグレードの注意点」や「例外的なパス」 が記載されていますので、慣れている作業でも必ず目を通しましょう。 ■ケースF：GUIの表示がおかしい 「DataKeeper更新後、GUI上でジョブ情報が表示されなくなりました」 解決策: 調査の結果、内部情報の不整合が起きていました。このケースでは、無理に修正するよりも「再インストールしてジョブを再作成」した方が、結果として早く、確実に解消しました。 教訓: バージョンが大きく離れている場合や挙動がおかしい場合 は、上書きアップデートに固執せず、設定バックアップをとった上での「作り直し（再作成）」が最短ルートになることがあります。 「再発させない！」成功へのチェックリスト 上記の失敗事例から導き出した、バージョンアップ作業前に確認すべき「転ばぬ先の杖」チェックリストです。計画段階でぜひご活用ください。 ■LifeKeeper/DataKeeper バージョンアップ事前確認シート [ ] 【パスの確認】 現在のバージョンからターゲットバージョンへ「直接」アップデート可能ですか？（中継バージョンが必要ありませんか？） [ ] 【設定ファイルのバックアップ】 更新時に初期化されるファイル（ /etc/default/LifeKeeper 等）を特定していますか？ それらの手動バックアップを取得し、更新後に復元する手順を組み込みましたか？ [ ] 【言語・環境の差異】 PerlやPythonなど、LifeKeeperが利用するランタイムのバージョンに変更はありませんか？（自作スクリプトへの影響確認） ディスクのパーティション形式は新しいバージョンの要件（UUID必須/GPT推奨など）を満たしていますか？ [ ] 【不要設定の削除（ゴミ掃除）】 IPリソースの pinglist に、現在疎通できない「亡霊IP」が残っていませんか？ [ ] 【OSとの整合性】 OS自体のカーネルアップデートを行う場合、LifeKeeperの再インストールやモジュール再コンパイルの手順を確認しましたか？ [ ] 【リカバリプラン】 更新インストールが不整合を起こした場合に備え、一度アンインストールして「新規インストール＋設定復元（または再作成）」に切り替える判断基準を持っていますか？ ベストプラクティス：成功への近道 トラブルを防ぐために、明日からできる「ベストプラクティス」を3つ提案します。 「リリースノート」は宝の地図 リリースノートを「バグ修正のリスト」だと思っていませんか？ 本当に見るべきは「制限事項 (Known Issues)」 と 「変更点 (Migration/Changes)」です。ここには「設定ファイルが初期化される」「UUIDが必須になる」といった重要情報が必ず書かれています。 ステージング環境でのリハーサルは必須 机上の確認だけでは、「pinglistのタイムアウト」や「Perlの互換性」といった環境依存のトラブルは見抜けません。本番環境のクローン（または同等構成）を用意し、実際にバージョンアップ手順を流すリハーサルを行ってください。 大幅な更新は「再作成」も視野に 数年前のバージョンから一気に最新版にするような場合、継ぎ接ぎのアップデートを繰り返すより、「設定情報を控えて、クリーンインストール後に再設定する」方が、潜在的なゴミが残らず、結果的に安定稼働につながることが多々あります。「上書き」にこだわらない柔軟性も重要です。 まとめ バージョンアップ時のトラブルは、多くの場合「準備不足」や「思い込み」の隙間に入り込むものです。 しかし、今回ご紹介した事例のように、事前に 「何が変わるのか」「何が消えるのか」「今の設定にゴミはないか」 を確認しておけば、そのほとんどは防げます。 「LifeKeeperの『困った』を『できた！』に変える」 今回のロードマップを参考に、ぜひ安心・安全なバージョンアップ計画を立ててください。 次回予告 次回からは新章に突入！ テーマは「クラウド環境特有の落とし穴：AWS/Azure連携でハマるポイント」です。 クラウドならではの「オンプレミスと同じ感覚で設定したら動かない！？」というトラブル。 その第一弾として、 AWS環境でのLifeKeeper安定稼働術 にフォーカスします。 「Route53のDNSが切り替わらない！」「便利なはずの『Auto Recovery』がLifeKeeperと喧嘩する！？」といったAWS特有の事例と、EC2・S3連携の注意点を徹底解説します。お楽しみに！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで
こんにちは。SCSK志村です。 Azure SQL Database で SQL Server を構成する際の設定項目に「接続ポリシー」があります。 設定値は「既定値」「リダイレクト」「プロキシ」の3種類から選択しますが、この「既定値」設定における挙動（特に Private Endpoint 利用時）について、私がドキュメントを読み間違えて悩んでしまったため、備忘録として記事にしました。 1. ドキュメントの記載 接続ポリシーは以下の公式ドキュメントに記載されています。 接続のアーキテクチャ – Azure SQL Database | Microsoft Learn ドキュメントによると、選択できるポリシーは以下の3つのオプションで構成されています。 リダイレクト (推奨): クライアントは、データベースをホストしているノードへの直接接続を確立します。これにより、待機時間が短縮され、スループットが向上します。 ※ポート 11000 - 11999 および 1433 の許可が必要です。 プロキシ: すべての接続が Azure SQL Database ゲートウェイ経由でプロキシ化されます。待機時間が長くなりスループットが低下する可能性がありますが、必要なポートは 1433 のみです。 既定値: 明示的に接続ポリシーを変更しない限り有効になる設定です。接続元に応じて、自動的に以下の挙動を使い分けます。 Azure 内からの接続（例：Azure VM） → Redirect として動作 外部からの接続（例：ローカルPC） → Proxy として動作 こちらの記事を読んで、私は最初、以下のような解釈をしていました。 当初の私の解釈： 「Azure内（仮想マシン）から発信する接続は『Redirect』だから、VMからSQL Databaseへの接続（Private Endpoint経由）も、リダイレクトになるはずだ。」 しかし、実際には Private Endpoint（プライベートエンドポイント）接続の場合、 既定値は「プロキシ」となります。 この事実は別のドキュメントに記載してありました。 Azure Private Link – Azure SQL Database | Microsoft Learn クライアントは明示的に リダイレクト接続ポリシーを選択する 必要があります。 既定 の接続ポリシーを使用する既存のプライベート エンドポイントでは、ポート 1433 でプロキシ接続ポリシーを使用します。 これを行う理由は、リダイレクトに必要なポート範囲が開いていないことが原因でクライアントのトラフィックが SQL Database に到達できなくなる状況を回避するためです。 Private Endpoint 経由では、リダイレクト接続ポリシーを明示的に指定する必要があるということですね。 リダイレクトに必要なポート範囲が開いていないことに対するケアとして、既定値がプロキシになっているようです。 事実はドキュメントからわかりましたが、せっかく調べたので実機検証もしてみました。 2. 実機検証 VMから Private Endpoint 経由で SQL Database へ接続した時の 接続ポート を比較してみました。 確認方式： SSMSで Azure SQL Database に接続し、 netstat コマンドで接続ポートを確認 検証結果サマリ まとめると以下の通りです。「既定値」は「プロキシ方式」で通信していることがわかります。 設定値 接続ポート 通信方式 リダイレクト 1433以外 (例: 12119) リダイレクト接続 プロキシ 1433 プロキシ接続 既定値 1433 プロキシ接続 参考：コマンド実行結果（クリックで展開） コマンド実行結果です。 ① リダイレクト設定の場合 ▼ netstat 結果：ポート 12119 (Redirect) TCP 10.0.0.4:53852 10.x.x.x:12119 ESTABLISHED ② プロキシ設定の場合 ▼netstat 結果：ポート 1433 (Proxy) TCP 10.0.0.4:53855 10.x.x.x:1433 ESTABLISHED ③ 既定値の場合 ▼ netstat 結果：ポート 1433 (Proxy) VMからの接続ですが、ポートは1433とProxyと同じポートになっています。 TCP 10.0.0.4:53860 10.x.x.x:1433 ESTABLISHED 3. まとめ Azure SQL Database への接続は、Microsoft としてはリダイレクトを推奨しています。 ※2026年2月時点でプロキシ推奨と読み取れる記述もありますが、恐らく自動翻訳によるミスです。 それにも関わらず既定値がプロキシなのは、ユーザーが複雑なネットワーク要件を意識せずとも繋がることを優先した安全側の設計思想だと思われます。（あくまで所感ですが） 接続方式の違いはパフォーマンスに直結するため、この仕様は設計時にしっかり把握しておきたいポイントです。 この記事が、Azure における SQL Database 設計のご参考になれば幸いです。
管理者
