技術情報 の記事一覧

本記事はGMOインターネットグループで複数ある開発者ブログのなかから人気の記事をピックアップして再掲載しています。機械学習や深層学習のビジネス応用を研究、社会実装をしているグループ研究開発本部 AI研究開発室のデータサイエンティストが寄稿した人気記事です。 TL;DR フランスのAIスタートアップであるMistral AIは、2024年7月16日に Codestral MambaというLLMを発表・公開しました。これはコード生成に特化したLLMで、従来のTransformerに変わってMambaという新しいアーキテクチャーを採用しています。公開されているCodestral Mambaをローカルで実行することも可能ですが、API keyを利用してOpen WebUIとLiteLLMを組み合わせてCodestral Mambaを実行してみました。Open WebUIを使うことでChatGPT風のGUIで、複数のLLMを簡単に切り替えたり同時に利用できるようになります。Mambaは状態空間モデルを利用することで、従来のTransformerよりも高速かつ効率的に長いcontext windowに対応できるとされています。Mambaは入力データをフィルタリングし、重要な情報のみを保持するSelection Mechanism、そしてGPUのメモリ構造を考慮した効率化、そして簡略化されたモデル構造が特徴です。更にTransformerと状態空間モデルとの対応関係をヒントに、Mambaを改良したMamba-2というモデルも開発されています。Codestral Mambaは、このMamba2を応用したLLMとして開発されています。 昨今のLLM技術の進展は、鬼が出るか蛇が出るか、まさか本当に蛇が出てくるとは 🐍 Codestral Mamba こんにちは、グループ研究開発本部・AI研究室のT.I.です。Mistral AIが、2024年7月16日に発表した「Codestral Mamba」という新しいLLMについて紹介します。Mistral AIとは、2023年にMetaやGoogle DeepMindの元従業員らによって創設されたフランスのAIスタートアップであり、これまでにMistral や Mixtral (Mistral の Mixture-of-Experts版)、Codestralなどのモデルを開発・公開してきました。今回新たに発表されたCodestral Mambaは、Code生成のタスクに特化したモデルです。Mistralのモデル名のお約束である「なんとかstral」はさておき、「Mamba」は一体何を意味しているのでしょうか？ 今日のLLMの基盤技術であるTransformerは、様々なタスクに対して高い性能を発揮するものの、入力長の二乗に比例して計算コストが増えるという問題があります。以前に、それを克服する手法として状態空間モデルを応用したS4やHyenaと、その応用例(HyenaDNA )をBlogで紹介してきました。今回のCodestral Mambaは、その発展系の１つである「Mamba(Mamba: Linear-Time Sequence Modeling with Selective State Spaces)」に基づいています。MistralはこのMambaに着目し、Codestral Mambaを開発しました。Mambaは、コブラ科のヘビの一属で、複数の種がアフリカに生息しています。高い毒を持っており、噛まれたら非常に危険です。それに因んでか、Mistral AIのCodestral Mambaの紹介では、以下のような文言が使われています。 As a tribute to Cleopatra, whose glorious destiny ended in tragic snake circumstances, we are proud to release Codestral Mamba, a Mamba2 language model specialised in code generation, available under an Apache 2.0 license.(DeepLによる訳) 栄光の運命を悲劇的な蛇の境遇で終えたクレオパトラへのオマージュとして、コード生成に特化したMamba2言語モデル、Codestral MambaをApache 2.0ライセンスで公開する。 同日にMistral AIは、Mathstralという数学の問題を解くためのLLMも発表していますが、そちらはアルキメデス(287 BC-212 BC)の生誕2311周年記念(?)だそうです。 Mistral AIの発表によるとCodestral Mambaは、Mambaの発表者であるAlbert GuとTri Daoの両名の協力のもと開発されました。彼らは状態空間モデルに深く関わってきた研究者で、Albert GuはS4、Tri DaoはHyenaの論文の著者です。Codestral Mambaは、Transformerの代わりにMambaを採用することで、従来よりも高速かつ効率的に長いcontext windowに対応することができます。検証では、25.6万トークンまでの入力に対応できることが確認されています。 Codestral Mambaの性能。Codestral Mambaは、Code生成のタスクに特化したモデルです。その性能は、複数のベンチマークでSoTAを達成しています。Codestral Mambaは、7B parameter のモデルですが、Codestral (22B)と比較しても同程度の性能を発揮しています。 Codestral MambaをOpen WebUI(+LiteLLM)で動かしてみた Codestral Mamba は、mistral-inference SDKやHuggingFaceでcheckpointをdownloadしてローカルで使用できます。簡単に使用するには、Mistral AIのLa Plateforme (https://console.mistral.ai/)にアクセスして、API KEYを取得するのが良いでしょう。今回はそのAPIを使用して、Open WebUIとLiteLLMを組み合わせて、ChatGPT風のGUIで使ってみました。 Open WebUIとは、ChatGPTっぽいUIでChatGPT(APIを使用)や、ローカルのLLMを使用できるアプリケーションです。異なるLLMを簡単に切り替えて利用できます。また、これにLiteLLMで建てたサーバーに接続することで、ChatGPTやGeminiなどのモデルを同時に利用できます(要API KEY)。こちらの記事を参考に環境を構築しました(Open WebUIがすごい)。この記事の場合AWS Bedrockへ接続していましが、今回は各種API KEYを利用して、ローカルで構築しました。なお、GPT-4oも利用できるように、Open AI APIとGPT-4oのモデルも追加してあります。 Docker Composeを使って、Open WebUIとLiteLLMのコンテナを立ち上げます。compose.yamlはこうして services: open-webui: image: ghcr.io/open-webui/open-webui container_name: open-webui volumes: - open-webui:/app/backend/data ports: - 8080:8080 environment: - 'WEBUI_SECRET_KEY=' - 'ENABLE_OLLAMA_API=false' - 'OPENAI_API_BASE_URL=http://litellm:4000' - 'OPENAI_API_KEY=sk-12345' # これはただのdummyなので適当で大丈夫です litellm: image: ghcr.io/berriai/litellm:main-stable environment: - 'OPENAI_API_KEY=${OPENAI_API_KEY}' - 'MISTRAL_API_KEY=${MISTRAL_API_KEY}' volumes: - ./litellm/config.yaml:/config.yaml command: [ "--config", "/config.yaml" ] volumes: open-webui: {} 利用するモデルについては、compose.yamlのあるディレクトリ以下にlitellm/config.yamlを配置して、以下のように設定します。 model_list: - model_name: OpenAI / gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: Mistral / Codestral Mamba litellm_params: model: mistral/codestral-mamba-latest api_key: os.environ/MISTRAL_API_KEY 環境変数で各種API KEYを設定して、docker compose upで立ち上げるだけです。簡単ですね。Open WebUIをブラウザで開いてアカウントを作成すると、既視感たっぷりな画面が表示されます。 Open WebUIのUI モデルとして、先ほどconfig.yamlで設定したモデルが表示されていますので、Codestral Mambaを選択して、あとはChatGPTと同じように使えます。Codestral MambaによるCode生成の結果の例。いくらか簡単な例を生成して試しただけですが、それなりにうまく生成してくれる感じです。生成速度もGPT-4oと比べても同程度で高速でストレスなく利用できます。 Open WebUIでCodestral Mambaを実行した例(右に浮かび上がっている緑色のGのアイコンはGrammarlyのプラグインなので無視しておいてください) ChatGPTなどでは、出力したコードのブロックには、コピーするボタンが付いていますが、Open WebUIの場合、更にRunというプログラムをその場で実行できる機能が付いています。特殊なライブラリが不要な標準的なコードに関しては、そのまま実行して結果を確認できます。 Open WebUIでCodestral Mambaで生成したコードを実行した例 Open WebUIの面白い機能として、複数のLLMを同時に利用できます。簡単な生成結果の比較には十分に使えるかもしれません。 Open WebUIでCodestral MambaとChatGPT-4oでコードを生成した例 なお、頑張ればいくらでもモデルを追加して同時実行可能です。下記の例は、GeminiやClaude、ChatGPTの複数のモデルを同時に実行しています。あまり多すぎるのも五月蝿くて使いにくいですので、精々２〜３個程度が限界かと思います。 Open WebUIで10種類のLLMに対してプロンプトを与えた結果の例 Mambaって何ですか？ さて、とりあえずCodestral Mambaを試すことはできましたが、Mambaとは一体何でしょうか？既存のLLMでは、計算コストが入力長の二乗に比例して増大するという問題があります。これはLLMの根幹になっているTransformerが、入力されたトークン間の組を全て評価するという原理的な弱点であります。これを解決する有力なアプローチとして状態空間モデル(State space model)を使った研究が注目されています。状態空間モデルとは、入力 u に対してシステム内部の状態 x を通じて出力 y が生成されるモデルです。時系列データや制御システムのモデリングに広く使われています。 x˙(t)=A(t)x(t)+B(t)u(t),y(t)=C(t)x(t)+D(t)u(t) この状態空間モデルを応用することで、計算コストの増加が入力長の二乗ではなく線形になるという利点があります。過去のBlogで紹介したS4やHungry Hungry Hippos (H3)、そしてHyenaなどがその代表例です。ここ最近、LLMやVLM、Stable Diffusionなどの紹介にかまけて手付かずでしたが、状態空間モデルに基づく研究も着実に進んでおります。その中でも特に注目されているものの１つが、昨年末に発表された「Mamba (Mamba: Linear-Time Sequence Modeling with Selective State Spaces)」です。日本ではKotoba technologyが、Mambaを日本語でも学習させた Kotomambaという2.8B parameterのLLMを発表しています。更にMambaの改良版であるMamba2 (Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality)が登場し、Codestral Mambaは後者を元にコード生成に特化したLLMとして開発されています。日本語でのわかりやすい解説としては、「 【Mamba入門】Transformerを凌駕しうるアーキテクチャを解説（独自の学習・推論コード含む）」が分かりやすくまとまっていますので、興味のある方は参照してみてください。 MambaとSelection Mechanism Mambaの重要なポイントは以下の３つです。 Selection Mechanism: 入力データに対して、重要でない情報をフィルタリングし重要な情報のみを保持Hardware-aware Algorithm: GPUのメモリ構造を考慮した効率化シンプルなモデル構造: H3やHyenaではTransformerに類似したQuery-Key-Valueの構造を持っていましたが、Mambaではそれらを更に簡略化した構造を採用 S4では、状態空間モデルのパラメーターとして、行列 A,B,C があります。h′(t)=Ah(t)+Bx(t),y(t)=Ch(t)これを時間の刻みを離散化(Δ)して、変数を変換するとht=A―ht−1+B―xt,yt=C―htこれは最終的に１次元の畳み込み演算で処理できます。K―=(CB―,CAB―,…,CA―kB,…),y=x∗K― S4では、これを効率的に計算するために行列に関しては特殊な条件を課しています。計算の効率は良いものの(A―,B―)は、時間のステップに依存しない一定の定数となっています。このLinear Time Invariance(LTI)という性質が、State Space Modelの計算効率と引き換えにある種のタスクへの性能を制限していました。この解決のために著者らが考案したものが、Selective State Space Modelsです。 TransformerのAttentionでは、情報を圧縮することなく全てのcontextを保持することで高い性能を発揮しますが、非効率でした。一方のRecurrent Neural Network(RNN)は、情報を圧縮することで計算効率を向上させていますが、性能としてはTransformerに劣ります。Selective State Space Models は、情報を圧縮する以下の２つのタスクに同期づけられて開発されています。 Selective Copying taskは、ランダムな位置にある覚えるべき重要なトークンをコピーするInduction Heads taskは、覚えるべきトークンが文脈に応じて変化し、それを記憶・回答 下記は、Copying taskとSelective Copying task, Induction Heads taskの概念図になります。色がある部分が重要な箇所で、黒は特殊なトークンを表しています。Copying taskでは、重要な情報が一定の位置にあるためにS4のようなLTIの性質を持つSSMで対応できます。しかし、Selective Copying taskでは、重要な情報はランダムに配置されています。また、Induction Heads task の場合では、黒のトークンの直前にあるものを覚えて回答する必要があります。これらのタスクに対しては、入力に動的に対応する必要があるためS4のようなLTIの性質を持つSSMでは処理が難しいです。 Copying taskとSelective Copying task、Induction Heads taskの概念図(図はMambaの論文より引用)。 このSelection Mechanismに対応するために、Mambaの論文では、SSM(S4)を改良したSSM+Selection(S6)という新しいアルゴリズムを導入しています。S6では、入力に応じて B と C、Δを動的に変化させます。 S6 Algorithm(図はMambaの論文より引用)。 Selective State Space Modelでは、S4で出来ていたような畳み込みでの計算効率化が出来ません。そこで、GPUのメモリ構造に合わせた効率化を行っています。GPUでは、HBM(High Bandwidth Memory)という大量・低速なメモリとSRAMという小容量・高速なメモリを組み合わせて使用しています。これらのメモリ間のデータのやり取りを減らすことで、計算効率を向上させています。以下は、その概念図となります。色は、各々のデータがどのメモリで処理されているかを示しています。入力 x に対して出力 y の計算には、latent state h や、各行列 A,B,C などの情報が必要ですが、SRAMを活用することで、HBMとのデータの移動を減らしています。 Mambaの処理におけるデータの流れ(図はMambaの論文から引用)。 Mambaのモデル構造は、下記の通りです。Hungry Hungry Hippos(H3)やHyenaが採用してた、Transformerに類似したQuery-Key-Valueの構造を持っていましたが、それらを更に簡略化した構造を採用しています。 Mambaのアーキテクチャ(図はMambaの論文より引用)。 以上のようにして考案されたMambaは、状態空間モデルをもとにしたfoundation modelで、計算効率の高さとTransformerに匹敵する性能さを両立しています。Mambaの論文中では、Selective Copying task, Induction Heads taskでのS6 Algorithmの有用性を検証し、自然言語処理やDNA sequence modeling、更に音声データ生成などのタスクでの従来のモデルとの性能評価を実施しています。Mambaが発表されたのは、2023年末ですが、その後、Mambaを応用した様々な研究が続々と発表されています。Awesome-Mamba-Papers (https://github.com/yyyujintang/Awesome-Mamba-Papers)に、まとめられています。Mambaに関する研究は、以下のように非常にハイペースで出ていることがわかります。 (Arxiv 23.12.01) Mamba: Linear-Time Sequence Modeling with Selective State Spaces(Arxiv 24.01.08) MoE-Mamba: Efficient Selective State Space Models with Mixture of Experts(Arxiv 24.01.24) MambaByte: Token-free Selective State Space Model(Arxiv 24.01.31) LOCOST: State-Space Models for Long Document Abstractive Summarization(Arxiv 24.02.01) BlackMamba: Mixture of Experts for State-Space Models(Arxiv 24.02.06) Can Mamba Learn How to Learn? A Comparative Study on In-Context Learning Tasks(Arxiv 24.02.08) Mamba-ND: Selective State Space Modeling for Multi-Dimensional Data(Arxiv 24.02.15) Hierarchical State Space Models for Continuous Sequence-to-Sequence Modeling(Arxiv 24.02.19) Pan-Mamba: Effective pan-sharpening with State Space Model(CVPR24) State Space Models for Event Cameras(Arxiv 24.02.26) DenseMamba: State Space Models with Dense Hidden Connection for Efficient Large Language Models(Arxiv 24.03.03) The Hidden Attention of Mamba Models(Arxiv 24.03.08) MamMIL: Multiple Instance Learning for Whole Slide Images with State Space Models(Arxiv 24.03.11) MambaMIL: Enhancing Long Sequence Modeling with Sequence Reordering in Computational Pathology(Arxiv 24.03.12) Motion Mamba: Efficient and Long Sequence Motion Generation with Hierarchical and Bidirectional Selective SSM(Arxiv 24.03.13) ClinicalMamba: A Generative Clinical Language Model on Longitudinal Clinical Notes(Arxiv 24.03.26) State Space Models as Foundation Models: A Control Theoretic Overview(Arxiv 24.03.28) Jamba: A Hybrid Transformer-Mamba Language Model(Arxiv 24.03.29) HARMamba: Efficient Wearable Sensor Human Activity Recognition Based on Bidirectional Selective SSM(Arxiv 24.04.07) VMambaMorph: a Visual Mamba-based Framework with Cross-Scan Module for Deformable 3D Image Registration(Arxiv 24.04.12) SpectralMamba: Efficient Mamba for Hyperspectral Image Classification(Arxiv 24.05.13) MambaOut: Do We Really Need Mamba for Vision?(Arxiv 24.05.19) NetMamba: Efficient Network Traffic Classification via Pre-training Unidirectional Mamba(Arxiv 24.05.23) EHRMamba: Towards Generalizable and Scalable Foundation Models for Electronic Health Records(Arxiv 24.05.26) Mamba4KT: An Efficient and Effective Mamba-based Knowledge Tracing Model(Arxiv 24.05.26) Zamba: A Compact 7B SSM Hybrid Model(Arxiv 24.05.30) MSSC-BiMamba: Multimodal Sleep Stage Classification and Early Diagnosis of Sleep Disorders with Bidirectional Mamba Transformersは状態空間モデルである: MambaからMamba-2へ さて、Tri DaoとAlbert Guの両名がICML2024で「Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality」(https://icml.cc/virtual/2024/poster/32613,https://arxiv.org/abs/2405.21060)という発表をしました(2024年7月24日)。その中で、Mambaの改良版としてMamba-2を発表しました。Codestral Mambaは、このMamba-2をベースにして開発されています。この研究では、従来のTransformerとSSMの関係を明らかにし、その関係を利用して、より効率的なモデルを設計する方法を提案しています。以下は、State Space Model と Attention、およびStructured Matricesという概念の関係性を示す図です。 SSMとAttention(Transformer)との関係性の概念図(図はMamba-2の論文より引用) S4などの論文でも議論されていましたが、ある特殊な構造を持つ行列(Structured Matrices)を利用することで、SSMの計算効率を向上させることができます。この研究では、Structured MatricesとAttention、SSMとAttentionの関係性を解き明かしています。このDuality(双対性)というものは、異なる２つの概念が実は表裏一体のものであることを指す言葉です。これらの対応関係を解き明かすことで、これまでに他の分野の研究で得られていた知見をSSMへと応用することが可能になります。Mamba-2では、この双対性を応用しモデル構造を改良し、従来のMambaから2-8倍もの高速化に成功しました。 Mamba-2のモデル構造(図はMamba-2の論文より引用)。Mamba-1では、X↦Y と処理していましたが 、Mamba-2では、A,X,B,C↦Y のようにパラメーター A,B,C に関する処理も並列しています。 まとめ 今回のBlogでは、Mistral AIが発表したCodestral Mambaについて、Open WebUIを使ったデモと、MambaというTransformerを置き換える可能性のある新技術を解説しました。Mambaの紹介が主だったので、あまり触れませんでしたが、Open WebUIは、GPTsのような機能や、ファイルの読み込みなどの多くの機能がありますので、興味のある方はぜひ試してみてください。(参考資料「Open WebUI (Formerly Ollama WebUI) がすごい」、「Open WebUI (Formerly Ollama WebUI) がすごい２（RAGもすごい）」)これまで状態空間モデルを使った研究は、着々と進められてはおりましたが、基礎研究が多く実用的なモデルはあまり出ていませんでした。今回、Mistral AIがMambaを採用したことでTransformerに依存しないfoundation modelが続々と登場する可能性があります。Mambaが一般化すると、Transformerを基盤としていた従来のモデルでは難しい長い入力長へのタスクが実現し、効率化することが期待されます。 さて、これからMambaが興味深いと調べると、2024年7月15日には、Tri DaoとAlbert Guらによる新しい研究が発表されていました。「Hydra: Bidrectional State Space Models Through Generalized Matrix Mixers(https://arxiv.org/abs/2407.09941)」蛇の次はHydraですか、Medusaとか出てきそうですね。 グループ研究開発本部 AI研究開発室では、データサイエンティスト/機械学習エンジニアを募集しています。ビッグデータの解析業務などAI研究開発室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ募集職種一覧からご応募をお願いします。皆さんのご応募をお待ちしています。 参考文献 Mistral AI Codestaral Mamba https://mistral.ai/news/codestral-mamba/Open WebUI https://openwebui.comLiteLLM https://www.litellm.aiMamba: Linear-Time Sequence Modeling with Selective State Spaces arXiv:2312.00752 https://arxiv.org/abs/2312.00752Transformers are SSMs: Generalized Models and Efficient Algorithms Through Structured State Space Duality arXiv:2405.21060 https://arxiv.org/abs/2405.21060過去のBlogでの状態空間モデルに関する記事・「Is Attention All You Need? Part 1 Transformer を超える(?)新モデルS4」https://recruit.gmo.jp/engineer/jisedai/blog/is-attention-all-you-need/・「Hyena: 次世代LLMへ向けたTransformerを超える新機械学習モデル Is Attention All You Need? Part 3」https://recruit.gmo.jp/engineer/jisedai/blog/hyena/・「HyenaDNA: DNAの言語を読み解くLLMの新たなる応用」https://recruit.gmo.jp/engineer/jisedai/blog/hyenadna/

本記事が対象としているのは、これからエンジニアになろうとしている方、エンジニア経験の浅い方、エンジニアとしてキャリアパスに悩んでいる方です。主に若手のエンジニアを想定しています。「プログラミングが好きだけど、仕事にしたらどうなるのだろう？」「エンジニアになったけど、キャリアパスってどう考えればいいの？」「自分の評価は正しいのだろうか……モヤモヤする」そんな疑問や不安に、趣味プログラマー45年、職業エンジニア30年、マネジメント歴20年、採用・教育歴10年以上の私の考えをお伝えします。 職業エンジニアの「役割」と「当面の目標」を知るメソッド エンジニアの領域 結論、「技術力」と「ビジネス力」の2軸で自分の立ち位置をマッピングし、そこから自分の「役割」「当面の目標」を判断しましょう。 使うのは、以下の図です。 スタート地点は人によって異なりますが、目指すのは右上の領域「花形エンジニア」です。 それぞれの軸の判断基準を説明していきます。 「どっかで見たことある」と思った方……そうです。プロダクトポートフォリオマネジメント（PPM）のエンジニア版です。PPMについては以下の記事で詳しく解説されているので、ぜひご一読ください。プロダクトポートフォリオマネジメントとは？メリットや企業の分析事例を解説 - GMOリサーチ&AIhttps://gmo-research.ai/research-column/product-portfolio-management 技術力（縦軸） プログラミングやサーバー構築など、純粋にエンジニアスキルのことです。それが仕事になっているかどうか、社会に貢献しているかどうかは関係ありません。シンプルに技術力で判断してください。 レベル判断基準一人前一人でWebサービスやアプリケーションを開発・提供できるレベルです。オープンソースへのコミットや、ちょっとしたライブラリを公開するレベルもここに含まれます。一人前～ハイレベルOSやプログラミング言語そのものを一人で開発できるようなレベルです。 「サービスやアプリは当たり前のようにつくることができる」「それ以外にも自分は○○のようなすごいことができる」 そう言える方は、このレベルに属していると思います。 ビジネス力（横軸） 「ビジネス力」と一言でくくりましたが、いろいろなスキルが含まれます。会計の知識・商品企画力・コミュニケーション力・マネジメント力などなど……「サービスを考えて」「実現し」「社会と会社に貢献する」ために必要な、技術力「以外」のスキルすべてと思ってください。 レベル判断基準一人前ビジネスの仕組みを理解しているレベルです。 社会がどうやって回っており、どうやって会社にお金が入ってきていて、それがどうやって自分の給料になっているのか、その仕組みを理解しているレベルです。会社の組織と役割についても理解できている状態かと思います。一人前～ハイレベル自らビジネスの拡大もしくは拡大の提案ができるレベルです。 そのためにはマネジメントや課題解決・企画提案など、様々なスキルが必要になってくるでしょう。   自分の属する領域を把握する この2軸にそってマッピングした場合、皆さんはどの領域のどの辺りにいるでしょうか？ 新卒・若手エンジニアの多くの方は、以下の辺りにいるのではないかと思います。 ご自身がどこにいるかで、会社や社会に対する「役割」、花形エンジニアになるための「当面の目標」が異なります。いずれにせよ、「花形エンジニア」以外の方は「花形エンジニア」になることが当面のゴールとなります。 領域ごとの「役割」と「当面の目標」 見習いエンジニア 技術力もビジネス力も、一人前以下の状態です。この領域にいる人は、だいたい「まだ一人前じゃない」という自覚があります。 あなたの役割は、先輩やリーダーからの指示に対して100%以上の成果を返すことです。仕事を進めながら、ビジネスの仕組みを勉強、未知の技術スキル習得を進め、いずれかの軸で一人前を目指してください。 「知らない」「やったことがない」仕事があればラッキーです。先輩やリーダーを質問攻めにしながら、どんどん取り組んでいきましょう。 「成長を感じない」のは危険信号です。すぐに先輩・リーダーに相談してください。 ギークエンジニア 技術力はあるけれど、ビジネス力が足りていない状態です。趣味プログラマーの人は、ここからスタートもしくはあっという間にこの領域に達することが多いです。 役割は、手持ちの技術力で会社に貢献することです。先輩やリーダーからの指示に対して100%以上の成果を返してください。もし自分より技術力が低い先輩やリーダー・仲間がいたら、彼らの技術面をサポートしてください。 技術力で会社に貢献しながら、ビジネスの仕組みを理解していくことが「当面の目標」です。ビジネス力が成長していけば、自然と先輩やリーダーから仕事を任せられるようになってくると思います。 社会人エンジニア 「見習い」状態から、ビジネス力が先に一人前になった方です。もしくは、すでに社会人として活動されている方が、エンジニアに転職されたパターンです。 あなたの役割は、「ビジネスがわかる」点を活かして、「要件の伝わりやすいエンジニア」（＝要件を伝えるのに手間がかからないエンジニア）として活動することです。チーム内に要件を理解していない人がいればサポートする、要件が曖昧だったら「こうですよね？」と確認する。 ビジネスを企画する人から出てくる要件は、エンジニアから見たら曖昧・矛盾していることがしばしばあります。そんなときに企画者を質問攻めにするのではなく、「こういうことですよね？」と企画者とエンジニアの隙間を埋めるようにしましょう。徐々に企画者やチームの仲間から信頼を得られるでしょう。 技術力が見習いレベルであることを忘れないようにしてください。花形エンジニアになるためには技術力は欠かせません。技術力の向上にも積極的に取り組んでください。 花形エンジニア 当面のゴールです。この領域まで来て、エンジニアとして初めて「一人前」と呼べると思っています。経験では、エンジニア歴5～10年ぐらいでこの領域に達する人が多いようです。 役割は、自身の「技術力」と「ビジネス力」で会社に貢献することです。指示待ちはダメです。自ら提案することで、組織に貢献しましょう。他の領域にいる人たちのサポートも、あなたの役割です。 花形エンジニアになってから先が、本当のキャリアパスなのですが、それはまた別の記事で語らせてください。以下の図のように「花形エンジニア」になってからのほうが、ずっとずっと広い世界です。 「半人前」に要注意 半人前とは？ 私の経験から、最も注意しなければならないのが「半人前」の方々です。ここをうまく導けるかどうかで、その人が花形エンジニアになるか、脱落（退職）していくかが決まります。 「半人前」とはギークエンジニア・社会人エンジニアの領域に属する方です。技術力とビジネス力、いずれかの軸が一人前ですが、もう一方の軸が見習いレベルです。 ひとつの軸が一人前なので、ご自身を一人前と勘違いする危険があります。例えば、以下のような疑問を抱いたことはないでしょうか？ 「自分は○○さんと同じスキルがあるのに、何で○○さんがリーダーなのか」「自分はこのサービスについてよく理解している。なのに何でリーダーをやらせてもらえないのか」 それは、ひとつの軸で他者と比較しているからです。「エンジニア」という仕事には、技術力とビジネス力、いずれも欠かせません。リーダーを、ふたつの軸で眺めてみてください。おそらく、いずれも一人前以上ではないかと思います。 ひとつの軸のみで他者と比較し、そこに疑問を持ち続けると、いずれは「自分は評価されていない」という不満になってしまいます。 他者と自分を比較する際は、必ず「技術力」「ビジネス力」のふたつの軸で比較するようにしてください。 ギークエンジニアが注意すること 「自分は技術力で勝負する（だからビジネス力はいらない）」という考えはとても危険です。 ビジネスの仕組みがわかっていない状態で「技術力」にこだわると、組織から浮いた存在になりがちです。「仲間にわからないコードを書く」「運営を意識しない実装をする」「つくるものの優先順位がおかしい」「職場環境への要求が多い」……仲間から「あの人、実力はあるけどチーム適応力がなくて困る」と思われてしまいます。結果、組織は扱いに困り、あなたも評価に不満を持つという、悪い状態になります。 「技術力で勝負する」という目標を実現するためには、ビジネス力を一人前にする必要があります。 社会人エンジニアが注意すること ビジネスがわかるからこそ、「○○のサービスを担当したい」「こうすればもっとよくなる」と思うことが多いでしょう。「エンジニアだからできる」とも思うでしょう。上流工程にシフトしたがる方もいらっしゃるのではないでしょうか？ でも、落ち着いてください。あなたにはまだ技術力が足りません。あなたはあくまでも「エンジニア」です。いま上流工程に注力してしまうと、「技術のわかる企画者」になるチャンスを失うことになります。 「技術のわかる企画者」になるためには、技術力を一人前にする必要があります。 規格外の人に「なろうとする」のはやめよう 規格外の人とは 何事にも例外があるように、このメソッドにも例外があります。いるんです。とんでもない人が。表現すると以下の通り。図の遙か外にいるような人です。 ウィザード 魔法みたいな技術力を持った人です。Excelマクロと同じレベルのマクロ言語を、スクラッチから3日でつくっちゃうとか、分散型ファイルストレージが一週間でできちゃうとか……そんな人です。2千人以上のエンジニアと仕事をしてきましたが、2名ほど出会ったことがあります。 CTO 新卒で入社した瞬間からCTOみたいな人です。決して技術力は高くないのだけれど、人を巻き込んで、一年目からプロジェクトリーダーをやったりします。なぜか経営陣まで巻き込んでいたりします。たいていの人は、2年目には独立して起業します。こちらも、過去に2名ほど出会ったことがあります。 目標にするのは危険 いずれも0.1%レベルのレアキャラクターです。有名になりがちなので、「目標にしよう」「あんな人になりたい」と思ってしまうかもしれません。 やめておきましょう。 おそらく彼らは、何らかの天賦の才を持って生まれています。「なろう」と思ってなることができるレベルではありません。「目標にしない」「なろうとしない」のが賢明です。 まとめ 職業エンジニアには「技術力」と「ビジネス力」が必要技術力とビジネス力で自分の立ち位置を把握しよう。立ち位置によって「役割」「当面の目標」は異なる。どんな人も、技術力とビジネス力の一人前以上（花形エンジニア）を目指そう。キャリアパスは、花形エンジニアになってから考えよう。

少し前に、ChatGPTなどの強力な大規模言語モデル（LLM）ベースの生成AIサービスが「9.11と9.9はどちらが大きいですか？」といった非常にシンプルな問題に引っかかったことが話題になりました。ネット上では「試してみた、本当に間違った」といった議論が多く見られましたが、それだけにとどめておくのはもったいないと感じたので、私なりに少し深掘りして考えてみました。 TL;DR 強力な主流生成AIサービスでも、簡単な数値比較や計算問題を間違えることがある。- これはトークナイゼーションの一部解釈から理解できる部分もあるが、本質的な原因ではない。LLMはそもそも数値計算を理解していなく、数値計算をしているのではなく、過去の学習データからそれらしい回答を思い出そうとしているだけと考えられる。正確な数値計算を行う場合、LLMに任せるのではなく、生成AIサービスにプログラムを書かせるのが良い。- プロンプトはシンプルに、「プログラムを実行して回答してください」と指示するだけで十分。生成AIをより有効に活用するためには、 「生成AIは何が得意で何が苦手なのか」 を理解し、 「道具として適切に使いこなす」 という姿勢が重要。 問題探索 今回の実験では、複数の主流生成AIサービスを同時に比較できる「天秤AI byGMO」サービス[1]を利用し、その上で提供されている以下の４つのLLMを対象に実験を行いました。（なお、天秤AIサービスはAPI経由での利用となるため、公式のチャットUIとは挙動が若干異なる場合があることをご注意ください） GPT-4oClaude 3.5 SonnetGemini 1.5 ProLlama3 70b Instruct LLMの生成結果にはランダム性があるため、以下全ての実験は5回程度繰り返して回しました。 9.11と9.9の比較 ではまずは、話題の「9.11」と「9.9」の大小を質問してみました。 入力文書 ：「9.11と9.9の大小を比較して」正解（例）：「9.11<9.9」 結果は以下のように分かれました（図１）: Gemini 1.5 Pro: 基本的に毎回正解GPT-4o, Claude 3.5 Sonnet: たまに正解するが、基本的には「9.11」の方が大きいと誤答Llama3 70b Instruct: 安定して毎回誤答 図１　「天秤AI byGMO」チャット画面、質問「9.11と9.9の大小を比較して」および各LLMの回答例構図（以降同様）左上：GPT-4o右上：Claude 3.5 Sonnet左下：Gemini 1.5 Pro右下：Llama3 70b Instruct この結果だけを見ると、Gemini 1.5 Proが一番優れていると思われるかもしれませんが、結論を出すのはまだ早いです。 質問を少し変えてみましょう： 入力文書 ：「5.11と5.9の大小を比較して」正解（例）：「5.11<5.9」 たった小数点前の9を5に変わるだけで、全てのLLMが不正解となりました（図２）。 図２　「天秤AI byGMO」チャット画面、質問「5.11と5.9の大小を比較して」および各LLMの回答例 なぜLLMはこんなにも単純な問題で間違ってしまうのかを探るために、とりあえず言い分を聞いてみました。LLMは自身の思考プロセスを完全に説明できるわけではありませんが、彼らの「言い訳」から、その特性や限界を垣間見ることができるかもしれません。 ここでは、長文にならないよう「理由を簡潔に教えて」と指示します（図３）。 図３ 天秤AI by GMO チャット画面、各LLMが質問「5.11と5.9の大小を比較して」の回答についての理由説明 全てのモデルが、小数点以下の「11」が「9」より大きいと誤って認識していることがわかります。つまり、LLMが小数点以下の桁数を正しく認識できていない可能性が高いですね。 そこで、桁数を揃えてあげれば、正しく判断できるのではないかと自然に考え思い浮かびますね。そのため、次のような質問もしてみました： 入力文書 ：「5.11と5.90の大小を比較して」正解（例）：「5.11<5.90」 想定通り、今度はすべてのモデルが安定して「5.90が大きい」と答えてくれました（図４）。有効桁数を揃えることの重要性がよくわかりますね。 図４ 天秤AI by GMO チャット画面、質問「5.11と5.9の大小を比較して」および各LLMの回答例 「strawberry」の「r」の数 次に、最近もう一つ話題となった問題「strawberry」の「r」の数について見てみましょう。 入力文書 ：「strawberryのrの数を数えて」正解（例）：「3」 前と似たような結果が出ています（図５）： Gemini 1.5 Pro: 基本的に毎回正解GPT-4o, Claude 3.5 Sonnet: たまに正解するが、基本的には「2」と誤答Llama3 70b Instruct: 安定して毎回「2」と誤答 図５ 天秤AI by GMO チャット画面、質問「strawberryのrの数を数えて」および各LLMの回答例 この結果を見ると、やはりGemini 1.5 Proが一番良いと思ってしまいますよね。しかし、今回も結論を出すにはまだ早いです。 先ほどと同様に、「理由を簡潔に教えて」を追加して理由を聞いてみましょう（図６）。 図６ 天秤AI by GMO チャット画面、各LLMが質問「strawberryのrの数を数えて」の回答についての理由説明 結果、Gemini 1.5 Proも含めて、すべてのモデルが「berry」の「r」を1つだけと誤認識していることがわかります。Gemini 1.5 Proは、「aw」の後に存在しない「r」をカウントして、たまたま正解を出しているようですね。 長い数字の0数 実は、似たような問題として、1年前にChatGPTが長い数字の0の数を間違えることがすでに指摘されていました[2]。 例として、このような質問をしてみます： 入力文書 ：「100000000000000000000000000000000には０がいくつ並んでいますか？」正解（例）：「32」 質問を複数回繰り返すと、Llama3 70b Instruct以外のモデルは時として正しい回答を返すこともありますが、、基本的には回答の一貫性がなく、誤答が多いです（図７）。 図７ 天秤AI by GMO チャット画面、質問「100000000000000000000000000000000には０がいくつ並んでいますか？」および各LLMの回答例 原因探索 トークナイゼーション 以上の結果から、LLMが文字列（特に数字列）の数を数えるのが苦手であることがわかります。その原因として真っ先に考えられるのが、トークナイゼーションの影響です。 トークナイゼーションとは、テキストを「トークン（Token）」と呼ばれる意味を持つ最小単位に分割する処理のことを指します。そして、このトークナイゼーションを行うモデルを「トークナイザー（Tokenizer）」と呼びます[3]。LLMは、このトークン単位でテキストを処理し、ベクトル表現に変換します。そのため、APIの課金もトークン単位で計算されることが多いのです。 トークナイゼーションは、一般的に隣り合う文字の出現頻度に基づいてトークンの境界を決定します。しかし、この仕組みが数字列のカウントにおいて、LLMに混乱を引き起こしている可能性があります。 Hugging Face上で公開されているCognitiveLabの「Tokenizer Arena」[4]を利用すると、複数の主要なLLMのトークナイザーを同時に比較することができます。このツールを利用して、各モデルがどのようにトークンを分割しているかを具体的に確認してみましょう。 先ほどの質問文のトークンを確認したところ、以下のようになっていました（図８）。 図８　Tokenizer Arena画面、各トクナイザーによる質問文のトークン分割の可視化構図は天秤AI by GMOのチャット画面に逐一対応（以降同様）左上：GPT-4o Tokenizer右上：Claude Tokenizer※1左下：Gemma Tokenizer※2右下：Llama3 Tokenizer 1. Claude 3.5のトークナイザーは公開されていないため、ここではClaude 3のトークナイザーを利用しています。ただし、変更点は非常に少ないと想定されます。2. Geminiのトークナイザーは公開されていないため、ここではGemmaのトークナイザーを利用しています。GemmaはGeminiと同じ技術で構築された軽量オープンモデルであり、両者は非常に似ていると考えられます。 数値の分割結果： Gemini（Gemma、以下省略）は、他のモデルと異なり、数字一桁を一つのトークンとして認識Gemini以外は、小数点以下の２桁数値「11」「90」を一つのトークンとして認識GPT-4o、Llama3は、3桁ごとに長い数値を区切るClaudeは、他のモデルよりもさらに長い数値を一トークンとして認識 「strawberry」の分割結果： Gemini以外のトークナイザーは、「strawberry」を3つのトークンに分割Geminiは「strawberry」を一つのトークンとして認識 Gemini以外の結果から、トークナイゼーションの影響が明らかです。 LLMの視点から見るとこうなります： 「5.11」と「5.9」の比較 ＝「⚪︎×□」と「⚪︎×△」の比較（且つ一般常識として「□」>「△」）「strawberry」の「r」の数＝「◇▽◎」の中の「r」の数「100000000000000000000000000000000」の「0」の数＝「▲◾️◾️◾️◾️◾️◾️◾️◾️◾️◾️」の中の「0」の数 それは、わかるわけないですね。 しかし、Geminiは他のトークナイザーとは異なり、少なくとも数字については1桁ずつを1つのトークンとして認識しています。もしトークナイゼーションだけが原因であれば、Geminiは適切に回答できるはずです。実際、上の質問に対するGeminiの回答は僅かに良く見える1ものの、正解からはまだ程遠い状況です。 LLMは数値計算を理解していない ここで着目したいのは、「なぜGPT-4o、Llama3のトークナイザーは、3桁ごとに長い数値を区切るか」という点です。 先ほど書いたように、一般的にトークンの境界は「隣り合う文字の出現頻度」に基づいて決定されます。つまり、3桁以内の数値の出現頻度は4桁以上の数値に比べて明らかに高く、このことから3桁目が境界として選ばれたと考えられます。 ここで思い出されるのは、一年前にChatGPTが登場した初期から、LLM（大規模言語モデル）は4桁以上の掛け算が間違いやすいという指摘があったことです[2][5]。 度重なるアップデートを経た現在も、この問題は解決されてないようです（図９）： 入力文書 ：「1204*1402」正解（例）：「1688008」 図９ 天秤AI by GMO チャット画面、質問「1204*1402」および各LLMの回答例 結果、Claude 3.5 Sonnet以外のモデルは、ほぼ毎回見た目が似ている異なる答えを出します。一方、Claude 3.5 Sonnetは自動的にステップバイステップで計算を行う2ため、常に正しい答えを導き出すことができます。 さらに、「1204*1402=1687408」とあえて間違った（かつLLMの誤答とも異なる）答えを教えて訂正してみます（図１０）。 図１０ 天秤AI by GMO チャット画面、訂正文「1204*1402=1687408」および各LLMの回答例 GPT-4o、Claude 3.5 Sonnet（元々正解していたにも関わらず）、Llama3 70b Instructは私が出した間違った答えをすんなり受け入れました。一方、Gemini 1.5 Proは自信満々に先ほど自分が出した誤答を言い張っていました。めちゃくちゃですね。 以上の結果を一般化してまとめると、LLMは以下のような傾向があります： 毎回異なる答えを出すただし、誤答の数値は、一見正しそうに見える間違った回答を教えても、疑わずに受け入れる 私は、LLM は数値計算をしているのではなく、過去の学習データからそれらしい回答を思い出そうとしているだけなのではないかと考えられます。 厳密に証明することは難しいですが、これまで見られた現象と辻褄が合っているように思います： 3桁以下の数値計算の精度が高い→ 学習データ中に多く見かけるため、暗記できている小数点以下の桁数が異なる数値の比較や、超長い数値から「0」を数えるのが苦手→ そもそも学習データにそのようなタスクが含まれていないため、適切な対応ができない4桁以上の掛け算の結果が、正しそうに見えても実際には正しくない→ 学習データにそのような数式は含まれていないが、近い形式の数式を見たことがあるため、それを元に近似して回答を生成しているステップバイステップで計算すると精度が上がる→ 学習データに見たことのない複雑な数式も、出現頻度の高い簡単な数式に変換することで、暗記された内容がより正確に再現される 一例として、6桁の掛け算をさせてみます： 入力文書 ：「890625 * 890625」正解（例）：「793212890625」 今度はGPT-4o、Gemini 1.5 Pro、さらにLlama3 70b Instructまで一発で正解を出せました。Claude 3.5 Sonnetは頑張ってステップバイステップで計算した結果、かえって間違ってしまいました（図１１）。 図１１ 天秤AI by GMO チャット画面、質問「890625 * 890625」および各LLMの回答例 なぜそうなるのか？それは「890625」は「自己同形数」であり、「8906252 = 793212890625」という有名な式がWikipedia[6]にも載っているためです。この情報がすでにLLMに学習されている可能性が非常に高いと考えられます。 LLMの学習ロジックは本質的に「次のトークンの予測（next-token prediction）」3に基づいており、これは「言語の法則」を使って予測しているに過ぎず、「数学的思考」とは根本的に異なります。 つまり、名著をたくさん暗記することで文章作成能力は向上しますが、数式をいくら暗記しても計算能力が向上するわけではないのです。 改善策 「LLMが簡単な数値問題を解けない」ことを指摘するだけが目的ではありません。適切な方法を見出し、正しい回答を導き出すことができるようになるのも重要です。 ステップバイステップ思考 多くの方になじみのある「ステップバイステップ思考」は、確かに一つ有効な手法です。実際に、Claude 3.5 Sonnetはデフォルトで掛け算の計算をステップバイステップで行おうとしています。 しかし、数値計算においてステップバイステップ思考は精度を大幅に向上させるものの、100%正解を出せるわけではありません（図１２）。 図１２　ステップバイステップで「strawberry」に含まれる「r」の数を数える過程の一例：1回目は正解だったが、2回目は誤りとなった場合 プログラムを実行して回答 LLMは、曖昧な表現も理解できる点が強みです。しかし、裏を返せば、正確性を追求することに向いてないです。LLMに100%の正確性を求めるのは木に縁りて魚を求むようなことです。正確性が求められる数値計算などは、生成AIのLLMに任せるのではなく、プログラムを使いましょう。これは、暗算が苦手な人が電卓を使うのと同じことです。 シンプルに、「プログラムを実行して回答してください」と指示するだけで良いのです。 ちなみに、ここでは「書いて」ではなく「実行して」と明確に伝える必要があります。そうしないと、コードを書いただけで回答が間違ったままになることがあります。 天秤AIはAPIを利用しているだけなのでプログラムを自動で実行することはできませんが、各生成AIサービスのUIでは実行可能です。 以下はChatGPTの例です（図１３ - １５）。 図１３　ChatGPT チャット画面、質問「プログラムを実行して回答してください　9.11と9.9の大小を比較して」およびプログラム表示回答 図１４　ChatGPT チャット画面、質問「プログラムを実行して回答してください　strawberryのrの数を数えて」およびプログラム表示回答 図１５　ChatGPT チャット画面、質問「プログラムを実行して回答してください　100000000000000000000000000000000には０がいくつ並んでいますか？」およびプログラム表示回答 実際、現在のChatGPTに掛け算の問題を出すと、デフォルトでは裏でプログラムを動かして回答しています（図１６）。ネット上ではたまに「LLMの計算能力が向上した」といった記事を見かけますが、それは当然のことですね。 図１６　ChatGPT チャット画面、質問「1204*1402」およびプログラム表示回答 おわりに OpenAI, Anthropic, Google, Metaといった企業の努力によって、LLMを含む生成AIは格段に使いやすく、私たちの生活に浸透しつつあります。しかし、「生成AIは万能である」という誤解は避けなければなりません。 現状の生成AIはあくまでも確率に基づいてそれらしい文章や画像を生成しているに過ぎず、その出力の正確性や倫理性については常に注意が必要です。 生成AIをより有効に活用するためには、 「生成AIは何が得意で何が苦手なのか」 を理解し、 「道具として適切に使いこなす」 という姿勢が重要になってくるでしょう。 素晴らしいことに、私がこの章の一段落目の文書をLLMに修正させた際に、Gemini 1.5 Proが自動的に最後の二段落の文書（太字付き）を追加してくれました。何も手を加えず、そのままここに掲載したいと思います。 参考資料 GMO教えてAI. "天秤AI byGMO". 天秤AI byGMO. https://tenbin.ai. (2024-08-06アクセス) 湊 真一. "ChatGPTはなぜ計算が苦手なのか". 国立情報学研究所. https://www.nii.ac.jp/event/upload/20230707-03_Minato.pdf. (2024-08-06アクセス) データアナリティクスラボ. "日本語LLMにおけるトークナイザーの重要性". Journal | データアナリティクスラボ. https://dalab.jp/archives/journal/japanese-llm-tokenizer/#i-4. (2024-08-06アクセス) Cognitive-Lab. "Tokenizer Arena". Hugging Face. https://huggingface.co/spaces/Cognitive-Lab/Tokenizer_Arena. (2024-08-06アクセス) tueda. "掛け算のできないChatGPT". Qiita. https://qiita.com/tueda/items/c04799a1eb8a2e46b9f6#fn-1. (2024-08-07アクセス) "自己同形数". ウィキペディア (Wikipedia): フリー百科事典. https://ja.wikipedia.org/wiki/%E8%87%AA%E5%B7%B1%E5%90%8C%E5%BD%A2%E6%95%B0. (2024-08-07アクセス) 

お久ぶりです。中村です。今回は私自身の備忘録も兼ねてZABBIXについてご紹介させていただきます。一度の記事で全てを説明するとあまりにも長くなってしまいますので複数回で記載させていただきます。 皆さんZABBIXってご存知？ 単に言うと、ZABBIXはサーバーやネットワーク、システム全体を24時間体制で見張ってくれる便利なツールです。ITインフラを管理している人にとっては頼もしい味方みたいな存在です。 例えば、サーバーが「ちょっと重いかも…」とか、「もうすぐディスク容量がいっぱい！」みたいな問題が起こりそうな時、Zabbixが事前に教えてくれます。つまり、トラブルが大きくなる前に早めに対策ができます。 しかもZabbixは、自分の好きなようにアラートを設定できたり、どんなデバイスやアプリケーションも監視できる柔軟性が魅力です。オープンソースなので気軽に試せるのもありがたいところです。 どんな監視ができるのか？ Zabbixは非常に多機能な監視ツールで、さまざまな監視を行うことができます。ほんの一部にはなりますがどんな監視が出来るかご紹介させていただきます。 1. 死活監視 まずは基本中の基本、死活監視です。これはサーバーやデバイスが正常に稼働しているかをチェックします。応答がない場合はアラートを発信し、迅速に対応できるようにサポートします。 2. ログ監視 次に、ログ監視です。システムやアプリケーションのログを監視して、特定のエラーや警告が出たときに知らせてくれます。これによって、トラブルの兆候をいち早くキャッチできるので、問題が大きくなる前に対処できます。 3. リソース監視（メモリ・CPU・Drive容量） Zabbixは、システムリソースの状態も把握できます。CPUの使用率、メモリの使用量、ディスクの空き容量などを監視します。「このサーバーはもうすぐDrive容量が足りなくなる！」といった予兆を早めにキャッチし、リソースの最適化や増強を計画することができます。 4. HTTP/HTTPSリクエスト監視 Webサービスの運用をしている方にはうれしい、HTTP/HTTPSリクエスト監視もできます。ウェブサイトやAPIへのリクエストが正常に応答しているか、レスポンスの速度はどうかなどを監視し、ユーザーに快適なサービスを提供できるようサポートします。 5. Webシナリオ Zabbixの特長の一つに、Webシナリオの監視があります。これを使うと、特定のウェブページの動作をシミュレーションして、その結果を監視することができます。たとえば、ログインから特定のページの表示までの流れを確認し、正常に機能しているかをチェックできます。 インターンなどで実施したZABBIX設定の例 数年前のインターンシップでは、minecraft-serverを題材にしたZABBIXの設定を行い、監視の重要性について学ぼう！といったことを行っていました。具体的には下記のような監視設定を行っていました。 メモリ使用率の監視（接続ユーザーが多人数になった際などにアラートCPU使用率の監視（TNT大量爆破など負荷のかかる動作でかかった際にアラートログ監視（ユーザーが実績獲得やゲームオーバーになった際にアラート セットアップ では早速ZABBIXをセットアップしていきましょう。今回の環境はubuntuを想定しています。 Webサーバのインストール Nginx/Apacheが使用可能です。本手順ではNginxのインストールを先に行っておきます #apt install nginx -y #systemctl status nginx #systemctl enable nginx データベースのインストール mysql/PostgreSQLが使用可能です。本手順ではmysqlのインストールを行います。 #apt install mysql-server -y #systemctl status mysql #systemctl enable mysql ZABBIXのインストール ありがたいことに基本のインストール手順については公式で準備されているページがあります。 https://www.zabbix.com/download? ubuntuでインストールを行う場合は下記を参考してください項目選択後は下部にコマンドが表示されるのでそちらに従いましょう。 グラフの文字化け対策 デフォルトでは日本語フォントがZABBIXに設定されておらずグラフが文字化けしてしまいます。こちらの文字化けを解決するためにあらかじめフォントのインストールを行いましょう。 #apt install fonts-ipafont-gothic #update-alternatives --install /usr/share/zabbix/assets/fonts/graphfont.ttf zabbix-frontend-font /usr/share/fonts/opentype/ipafont-gothic/ipagp.ttf 20 #update-alternatives --config zabbix-frontend-font Webページからの初期設定 デフォルトの設定であれば【http://IP:8080】で接続が可能です。あとは下記ページを参考にセットアップを行います。 https://www.zabbix.com/documentation/6.4/jp/manual/installation/frontend ログインしてダッシュボードの確認 セットアップ後は下記でログインが可能です。 ID：Admin PASS：zabbix 本題の監視設定について 本題の監視設定については実例を交えたものを、次回以降にご紹介させていただきます。お楽しみに！ 宣伝 ConoHa VPSでも、ZABBIXの構築が可能です！もし、気になる機能がある方は是非ConoHaで試していただければ幸いです！

今回は「AIでテクノロジーの未来を切り拓く」をテーマに行われたDell Technologies Forum Japan 2024での弊社講演についてのレポートをお届けします。このセッションは「AI時代に向けて」というタイトルで、デル・テクノロジーズ株式会社と合同で行ったセッションとなりますが、今回のレポートではGMOインターネットグループが行った超高速マルチクラスタ構築の秘話にフォーカスしてお届けします。 スピーカープロフィール GMOインターネットグループ株式会社　中村 槙吾 スピーカーは、GMOインターネットグループ新卒7年目になる中村 槙吾さんです。主な業務は物理/OS/ミドルウェアにかけての構築や開発がメインとなりますが、実は彼は技術広報チームの兼務メンバーとしても活躍してくださっています。こういった社内外イベントでの登壇や、本ブログでも記事を執筆してくださっているので、宜しければ是非そちらもチェックしてみてください。 →記事一覧 本編その①-採用機種の紹介 「怪物襲来」として紹介された木箱に梱包されていたのが、今回サーバーマシンとして導入したデル・テクノロジーズの「PowerEdge XE9680」、その数なんと96台。そして、この機器に導入されているのがNVIDIA製の最新GPU H200です。FP8 TensorCore 3958TFLOPS の圧倒的な計算能力とTDP700Wという威力をもつこのH200が「PowerEdge XE9680」1台になんと8枚も搭載されているそう。また通信をつかさどるNICのスペックもスバ抜けていて、通常コンシューマー向けでは10Gb/sが一般的と言われるなか、何と400Gb/sを8枚搭載しているそう。 サーバーがモンスターマシンならなら対向のネットワーク機器もモンスターマシンです。今回はNVIDIA製の800G×64Portというスペックの機器を導入しています。この超高速な帯域を使って実現できる技術が「Spectrum-X」になります。これはサーバーに搭載されているNICとGPU1つずつを紐づけて、複数のサーバー間で全てのGPUをインターコネクトするという技術です。この技術を使用することで大規模な学習や計算を効率よく行うことが可能です。サーバからNICが8本、ネットワーク機器までのケーブルを長さを合わせると直線距離で40km・・・大阪市～京都市くらいの距離になりますね。 本編その②-導入の裏側 ここからは、導入の裏話をご紹介します。 ①設置高さが6U、重量が113.3kgにもなる「PowerEdge XE9680」これは5人家族向けの冷蔵庫と同重量だそう。人力でのラックマウントは危険が伴うため、電動のサーバーリフターを使用します。 ②排熱サーバー1台の消費電力は11,700W、これは電子レンジ700Wを16台同時に動かすくらいの電力です。これだけの電力を使うということは、それだけ放出する熱の量もすごいということなのですが、ここで私たちが行った施策は2点。排熱側の対向ラックに機器を設置しないこと、排熱側に風を上に吹き上げるフィンをつけて効率的な冷却を行っていることです。これらはCFDシミュレーションで解析され、効果をきちんと可視化し管理しています。 ③騒音これらをフル稼働させた際の騒音レベルは、なんと108db！自動車のクラクションとほぼ同じくらいの騒音レベルだそうで、作業をする際は防音イヤーマフが必需品です。 ここまでで、物理的施策が完了ですがOSレイヤーの設定が山のように残っています。特に今回はSpectrumXのような最新技術を使用するため、専用の設定や概念の理解、また今回のサービス向けに最適化するには？といった部分まで考慮する必要がありました。多くのリファレンスを読み、メーカー公式サポートのお力も借り、検証を終え、ようやく動かすことができました。 物理構築、機器設定、大変だったここまでの作業はもう不要です。 本編その③-新サービス「GMO GPUクラウド」について ＧＭＯインターネットグループでは、生成AI開発や機械学習に最適化された業界最高峰のGPUクラウドのご提供準備を進めています。 サービスの特長としては 大規模言語モデルの開発・研究者向けにGPUメモリ容量とメモリバス帯域幅を大幅に拡大・最適化した「NVIDIA H200 Tensor コア GPU」を国内最速提供AIワークロード専用に設計された世界初のイーサネットファブリックであるSpectrum-Xを国内で初めて採用GPUの性能をフルに発揮できる超高速/大容量ストレージであるDDNのストレージを採用NVIDIAが提供する一元管理されたプラットフォームで幅広いソフトウェア、管理ツール、ワークロードなどを提供可能クラスタシステムのための業界標準であるジョブスケジューラー「Slurm」を採用 ということで、最後はGMO GPUクラウドについてのご紹介でセッションを終えました。本サービスは現在、トライアルも受付中です。詳しくは下記Webページをご覧ください。GMO GPUクラウド　https://www.gmo.jp/gpucloud

こんにちは。新里です。9月は個人的にはイベントが連続して、人生でこんなにハードな週はあるのか？と思うほど、ハードな週がやってきました。・Japan Robot Week : 2024/10/18-20 東京ビックサイト 東ホール・Maker Faire Tokyo : 2024/10/21, 22 東京ビックサイト 西ホールこの期間は毎日、東京ビックサイトでイベントということに。それぞれのイベントについて、少しレポートします。 Japan Robot Week ビックサイト正面に設置された展示一覧 2024/10/18(水) 〜 20(金) 東京ビックサイト 東ホールで開催されました。GMO AI&ロボティクス商事の展示はこちらのように、多くの企業さま・ロボットの協力に支えられて行われました。 全ロボットが集合 全てのロボットが一斉に揃うと圧巻ですね。GMO AI＆ロボティクス商事は今年の6月に出来たばかりの会社で、これからGMOのサービスと共創を進めて行けたらと。 ただ、個人的にはどうしても技術者目線・サービス目線になってしまい、セキュリティ・ネットワーク、組込み・シュミレーション、LiDAR/SLAM、位置制御、フィードバック、力覚、AI的な推論のエッジ・クラウドでの処理、データのモデル化などなど...話をし始めると、どれだけ時間があってもディスカッションになりますね。 個人的には...と付け加えておいて。空間とヒトとデジタルデータ化の扱いについては、ヒトとコンピュータ・ロボットとの関わりに通じてくると考えている。大量のセンサーデータを使った機械学習での推論のように、「コンピュータが予想して動いて、出した結果をヒトがどう感じるか？そのヒトのフィードバックをコンピュータに戻して再計算して...」のように、コンピュータとヒトとの関わり方から、そもそもヒト・意識とは何か？という所まで再帰的に考える事ができる機会にもなれば面白いと、個人的には考えていたりもします。 Maker Faire Tokyo 2024/10/21(土) 〜 22(日) 東京ビックサイト 西ホールで開催されました。Maker Faire Tokyo 2024 作ることで、楽しむ、つながる、学ぶ というテーマですね。 電子工作やロボット的な物だけでなく、クラフト・モビリティ・デザイン・音楽・科学・宇宙・アート・ハック... と分野も多様で、展示物も超大量です。 一体いくつの作ったモノが展示されていたのか？自分が見て回った分では、四分の一くらいしか見れてなかったような気が。本当に超大量の作品がありました。 ぐはぁ...ビックサイト行脚 ここからが、この記事のメインです。Japan Robot Week 〜 Maker Faire Tokyo 5日間 ずっとビックサイトに居る予定になった。まず、それぞれのイベントの予定がFixedしたのが...・Maker Faire Tokyo 2024 出展承認 2024/06/20・Japan Robot Week キックオフ 2024/06/25日程とかは全然見てなかったものの、カレンダーを見てみたらあらまぁ...だった。 カレンダーを見て、ようやく事態の深刻さを理解した（逃げちゃダメだ...という言葉がリフレインでしたね)。１．Maker Faire Tokyo 2024 には約600個ものソレノイドを持っていく。重量ヤバい。２．20日のMFT設営日はJapan Robot Weekと被ってしまっている。３．５日間ずっとビックサイト、ずっと展示イベントで自分の体力は大丈夫か？ 先にMaker Faire Tokyoが承認されて出展が決まっていたというのもあって、9/20(金) は有給休暇にすることにしました。個人での展示ではありますが、先に決まった方が優先されるのは当然です。これで２はクリアすることに。 Maker Faire Tokyo 2024 設営後の状態 ソレノイドは、ほぼ鉄の塊で小型ソレノイドといっても600個弱は凄まじい重量になる。そのうち、約100個を配布物としようと思っていて、自分のMaker Faire Tokyoの準備は約1ヶ月前から行うことに...・配布物の準備・展示物の動作確認、不具合チェック、補修・展示物の梱包・移動耐性チェック... やる事はなんぼでも沢山あった展示物の梱包は9/15(日)に終わらせて、あとは持っていくだけという状態にしておいた。これで、問題の１、２はクリア（ということにした）。問題３については、もう自分の体力が続く限り...昭和な根性論で対応することに。 イベント週が終わって... ５日間を通じて...詰め込みはヤバいというのを実感した。ただ、やってみれば、何とかなるという経験にもなったりした。

この記事では、AIの発展に伴うデータ管理の重要性と、OpenZFSがAIワークロードに最適なストレージソリューションである理由を説明します。OpenZFSの特徴として、データ整合性の確保、高パフォーマンス、スケーラビリティ、スナップショット機能、効率的なデータ管理、セキュリティ機能が挙げられます。 AIの未来においてOpenZFSが果たす役割の重要性にも言及されています。 はじめに 人工知能（AI）は、複雑なタスクの自動化、よりスマートな意思決定の促進、ユーザー体験の向上によって、産業界を急速に変革してきました。AIが進化を続ける中で、ひとつの課題が常に存在します。 それは、AIモデルが依存する膨大なデータを管理するための、堅牢でスケーラブルかつ安全なストレージソリューションの必要性です。高度なオープンソースファイルシステムであるOpenZFSは、このAI主導の未来を実現するための重要な役割を果たし、AIワークロードに必要なパフォーマンスと信頼性を提供します。 AIにおけるデータの役割 データはAIの生命線です。機械学習モデルは大量のトレーニングデータを必要とし、AIシステムは効果的に動作するために絶え間ないデータの入力に依存しています。 このデータは、構造化されたデータベースから画像やビデオのような非構造化データセットまで、さまざまな形式で保存されます。AI用のシステムを設計する際には、データの保存、アクセス、処理の効率が極めて重要となります。 AIワークロードにOpenZFSが最適な理由 AIトレーニングのためのデータ整合性 AIモデルのトレーニングは正確で信頼性の高いデータに大きく依存しています。たった一つの破損したファイルでも、予測の精度低下や誤った出力につながる可能性があります。OpenZFSはEnd-to-Endのチェックサム機能によってデータの整合性を確保し、保存中および転送中のデータを破損から保護します。データの正確性が最重要であるAIアプリケーションにとって、これは非常に価値のある機能です。 高いパフォーマンスとスケーラビリティ AIシステムはしばしば大規模なデータを処理し、テラバイトやペタバイト規模の情報を効率的に扱えるストレージソリューションを必要とします。 OpenZFSは、高度なキャッシング（ARC）、書き込み最適化（ZIL）、負荷の高いI/O操作の効率的な処理能力といった先進的な機能を通じて高いパフォーマンスを提供します。そのスケーラビリティにより、AI主導の企業は小規模から始め、データニーズの拡大に合わせてストレージインフラをシームレスに拡張することができます。 スナップショットとデータのバージョン管理 OpenZFSの最も強力な機能の一つは、スナップショットとデータのバージョン管理のサポートです。 AI開発において、これは特に有用です。例えば、スナップショットにより、開発者は特定の時点でのデータセットの状態をキャプチャすることができます。これにより、モデルの実験、データの以前のバージョンへのロールバック、再現性の確保（AI研究の重要な側面）が容易になります。 重複排除と圧縮による効率的なデータ管理 AIに関する処理は、大量の冗長データを生成することがあります。特に同じデータセットの複数バージョンを扱う場合です。OpenZFSはインラインの重複排除を提供し、重複するデータブロックは一度だけ保存して再利用することで、全体のストレージ容量を削減します。透過的な圧縮と組み合わせることで、パフォーマンスを犠牲にせずにストレージコストを節約することができます。 セキュリティとコンプライアンス AIモデルはしばしば、ユーザー情報、財務記録、機密研究などの機密データを扱います。OpenZFSはネイティブ暗号化機能を提供し、不正なアクセスからデータを保護します。また、ロールベースのアクセス制御（RBAC）や監査ログを提供し、GDPRやHIPAAなどのセキュリティ規制への準拠を容易にします。 ユースケース、AI研究機関と企業 AI分野におけるOpenZFSの実際の適用例として、膨大なAI関連データを扱う研究機関や企業があります。OpenZFSは、大規模なAIモデルがトレーニングされ、処理され、改良される環境でますます導入されています。その柔軟性により、オンプレミスとクラウドストレージソリューションを混在させたハイブリッド環境に最適であり、AI研究チームはデータがどこに保存されていても、一貫した高速アクセスが可能になります。 例えば、ディープラーニングモデルに取り組むAI研究チームは、OpenZFSを使用してトレーニングデータを保存し、モデルの出力をログに記録し、データセットのバージョン管理を行うことができます。その際、データが安全であり、障害時にも容易に復旧できることが保証されます。パフォーマンスやセキュリティを損なうことなくストレージをスケールアップできる能力は、OpenZFSをAI研究エコシステムにおける重要な資産としています。 AIとOpenZFSの未来 将来を見据えると、AIとOpenZFSの相乗効果はさらに強まるでしょう。AIモデルがより複雑になり、高性能な演算能力の需要が高まるにつれて、先進的なストレージソリューションの必要性も増大します。OpenZFSの開発ロードマップには、クラウド統合の改善、SSD向けのさらなる最適化、データセキュリティの強化などの機能が含まれており、これらはすべてAIインフラの未来を形作る上で重要な役割を果たします。 OpenZFSとAIの組み合わせにより、企業は大量のデータを処理するだけでなく、それを信頼性が高く、安全で、コスト効果の高い方法で行うことができます。OpenZFSをAIデータインフラの基盤として活用することで、企業はデータが安全で効率的に管理されているという安心感のもと、革新的なAIソリューションの開発に専念することができます。 まとめ AIがイノベーションの未来を牽引する中、OpenZFSのような堅牢なデータストレージソリューションの必要性はますます重要になっています。OpenZFSは、AI主導の企業を支えるために必要な信頼性、パフォーマンス、スケーラビリティを提供し、AIによって駆動される未来を構築する上で不可欠な要素となっています。OpenZFSをAIシステムに統合することで、企業は技術革新の最前線に立ち、データを実用的な洞察に変えると同時に、AIインフラが将来の課題に備えていることを保証できます。 OpenZFSとAIは強力な協力関係を形成し、可能性の限界を押し広げ、データと知能が手を取り合って働く未来へと私たちを導きます。 著者について ファイルシステムに深い専門知識を持つ経験豊富なソフトウェアエンジニアとして、私は複数のアーキテクチャに対するOpenZFSの開発に長年貢献してきました。GMOインターネットグループのエンジニアとして20年以上にわたり、必要に応じてZFSストレージを使用しています。OpenZFSの開発者会議や年次のOpenZFS Developer Summitに積極的に参加し、他の業界リーダーとともにZFS技術の限界を押し広げています。 私の情熱は、最先端の技術と堅牢で信頼性の高いストレージシステムを橋渡しし、企業が未来の要求に応えるために必要なツールを確実に持てるようにすることです。

GMOインターネットグループの梅崎です。今回はネットワーク通信に必要なケーブル部材の話を、独断と偏見によるピックアップでご紹介できればと思います。 メタルケーブル いわゆるLANケーブルについてです。(人によっては「RJ45」「STP/UTPケーブル」「ツイストペアケーブル」「メタルケーブル」などと呼ぶこともあります) コネクタ形状 「RJ45」というものだけ覚えておけば大丈夫です。配線はほとんど「ストレート」なので、「クロス」はそんなのもあったな程度に覚えておけば十分です。 ケーブルの種類 「Cat5e」と「Cat6/Cat6A」だけで十分かと思います。注意点としては「Cat5相当品」を名乗る、中の線が足りないものがあるので記憶の片隅に入れておいてください。それぞれの用途としては「Cat5eが1Gbps以下」、「Cat6Aが10Gbps以下」での接続で使います。(余談ですが10Gbps以上は基本的に光ファイバーを使うほうが面倒が少なくていいと思います。メタルケーブルはノイズを拾って通信品質が劣悪になった経験が……) その他にもケーブルの直径でAWGxxという番号もあったりします。(PoEでの電力や接続距離に制限がかかることがあるので、細さはほどほどにしたほうが吉です) 光ファイバー コネクタ形状 「LC」「MPO」をよく使い、「SC」はたまに使うので、この3つを覚えておけば大丈夫です。「LC」「SC」は一つのコネクタに1つの心線が入っており、「LC」が小さめ、「SC」がちょっと大きめな形をしています。「MPO」は一つのコネクタに複数の心線が入っており、MPO8かMPO12をよく使います。(MPO24とかもあるらしいですが、今のところこれを利用する光トランシーバーを使ったことはないです) 「MPO8」は「MPO12」の使わない心線がないもののようです。現状は「MPO8」のみで十分かと思いますが、念のためMPO12を購入してもいいかなと考えています。 両端のコネクタ形状が異なるケーブルもあります。例えば・「MPO8」を8本の「LC」にバラしたもの・片側は「LC」、もう片側は「SC」になっているものがあり、用途(光トランシーバーの形状など)によって使い分けるのに便利です。 「MPO」の配線はいくつかの種類があるので、使う光トランシーバーに合わせて使い分けてください。 その他にもファイバーの端面の形で角度がついていないものと角度がついているものがあります。互換性がないのでご注意を。 ケーブルの種類 「シングルモードファイバー(SMF)」、「マルチモードファイバー(MMF)」がありますが、光トランシーバーのレーザーの種類で使い分けると覚えておけば大丈夫です。 ざっくりと短距離であればMMF、長距離であればSMFが使われることが多いです。 また、「SMF」「MMF」それぞれに「OS1」「OS2」、「OM3」「OM4」といった種類があり、同じ光トランシーバーでも、ケーブルによって接続可能な距離が違うと思っておいてください。 その他 「DAC」や「AOC」と呼ばれる光トランシーバー部分とケーブルが一体化されているものも存在します。「DAC」が光トランシーバーの形状で金属のケーブルがつながったもので、「AOC」が光トランシーバーに光ファイバーがつながったものです。 「DAC」は超短距離用で10m以下、「AOC」はそれよりは長く100m以下で使うことが多いです。 最後に 以上、私がよく使うケーブル部材について話してきました。 ケーブルの端面形状についてや「LC」よりも小さなコネクタ形状など、今回割愛した内容については、ケーブルやNW機器のメーカーさんのサイトも見ると面白いですよ、と丸投げしつつ筆を擱こうと思います。

こんにちは、アプリケーション開発を担当している田中です。オンプレミス環境からAWS環境へバックエンドAPIを移行しました。移行対象のコマンド数が100本ほどあり、リスク軽減のため段階的に移行をしたので、どう段階移行を実現したのかを書いておこうと思います。 要件 現行環境（オンプレ）と新環境（AWS）を並行稼働し、APIコマンドを段階的に移行する移行はURLパスごとのかたまりで行う※sample-api-app.io/{機能名}/* 程度の単位でいくつかに分割して順次移行ホワイトリスト形式のIPアドレスベースのアクセス制限を行う（現行踏襲）IPアクセス制限はURLパス単位に設定できるようにする 前提 現行環境（オンプレ）と新環境（AWS）間は、インターナルなネットワークで接続が可能手前にクラウドWAFがあり、このWAFにより接続元IPがヘッダー情報に格納されるため、アクセス制限の際はヘッダーからIPを参照する 段階移行のイメージ 構築手順 1. URLパスベースの振り分け 振り分けはALB（Application Load Balancer）のリスナールールで行います。ALBのパスベースでの振り分け設定方法は「ALB パスベースルーティング」などでネット検索するとたくさん出てくるので、コンソールからの設定方法は割愛します。のちほどterraformのサンプルコードを記載しているので参考にしてみてください。以下２つのリスナールールを用意し、それぞれに条件を追加します。 ■80ポートのリスナールール HTTPS（443）へリダイレクトする ■443ポートのリスナールール現行環境（オンプレ）VMのIP群と、新環境（AWS）のECSタスクのIP群のターゲットグループをそれぞれ作成した上で以下の条件をリスナールールに追加します。 新環境（AWS）への振り分け対象URLパスパターンの場合、新環境のターゲットグループへ振り分け1つのリスナールールに付与できる条件は最大5つなので、5つ以上のパスパターンを振り分ける場合は上記と同様のリスナールールを追加すべてのアクセス（/*）を現行環境（オンプレ）のターゲットグループへ振り分け（この条件を最も低い優先度で登録し、上記条件に一致しないパスをすべてオンプレへ転送します） 2. IPアドレスでのアクセス制限 IPアドレスによるアクセス制限の方式は、以下3つの方式から検討し、AWS WAFによるアクセス制限を採用しました。 AWS WAFこれを採用した◯ALBリスナールール1ルールにつき5条件までしか設定できず、適用するパスを限定する条件設定と組み合わせると複雑になってしまう△セキュリティグループヘッダー情報を条件に制限がかけられないため要件を満たせない✕IPベースのアクセス制限方式を検討 3. terraformサンプル 弊社ではAWSリソースをterraformで実装してコード管理しています。以下にterraformで実装した際のサンプルコードを掲載します。今回はVPCやサブネット、ECSリソースは別のモジュールで作成するものとして割愛しています。また、CodeDeployによるBlue/Greenデプロイを想定してBlue/Greenそれぞれのリスナーを用意しています。 ディレクトリ構成 main.tf modules ├alb │ ├alb.tf │ ├target_group.tf │ ├variables.tf │ └outputs.tf │ ├waf │ ├waf.tf │ └variables.tf │ main.tf locals { application_name = "sample-api-app" } # -------------------------------------------------------- # Application Load Balancer # -------------------------------------------------------- module "alb" { source = "../../modules/alb" application_name = local.application_name private_subnet_ids = module.network.vpc.private_subnets # 別途moduleを作って作成してください certificate_arn = "arn:aws:acm:ap-northeast-1:xxxxxxxxxxxx:certificate/uuuuuuuu-uuuu-iiii-dddd-000000000000" security_group_id = module.security_groups.alb.id # 別途moduleを作って作成してください vpc_id = module.network.vpc.vpc_id # 別途moduleを作って作成してください aws_health_check_path = "/aws-health-check-path" # アプリケーションに合わせて設定 onpre_health_check_path = "/onpre-health-check-path" # アプリケーションに合わせて設定 routing_paths1 = ["/aaa*", "/bbb*", "/ccc*", "/ddd*", "/eee*"] listener_rule_priority1 = 1 routing_paths2 = ["/fff*", "/ggg*", "/hhh*", "/iii*", "/jjj*"] listener_rule_priority2 = 2 } # -------------------------------------------------------- # AWS WAF # -------------------------------------------------------- module "waf" { source = "../../modules/waf" application_name = local.application_name alb_arn = module.alb.aws_alb_arn allowed_ip_address = [ "xxx.xxx.xxx.xxx/32", "yyy.yyy.yyy.yyy/30" ] ip_header_name = "X-WAF-Connecting-IP" # 手前のクラウドWAFで接続元IPアドレスが格納されるヘッダーのパラメータ名 } modules/alb variable "application_name" { type = string description = "アプリケーション名" } variable "private_subnet_ids" { type = list(string) } variable "certificate_arn" { type = string description = "証明書のARN" } variable "security_group_id" { type = string } variable "vpc_id" { type = string } variable "aws_health_check_path" { type = string } variable "onpre_health_check_path" { type = string } variable "routing_paths1" { type = list(string) } variable "listener_rule_priority1" { type = number } variable "routing_paths2" { type = list(string) } variable "listener_rule_priority2" { type = number } locals { # ALBの名前は32文字まで alb_name = "${substr(var.application_name, 0, 28)}-alb" } # -------------------------------------------------------- # ALB # -------------------------------------------------------- resource "aws_lb" "alb" { name = local.alb_name internal = true load_balancer_type = "application" security_groups = [var.security_group_id] subnets = var.private_subnet_ids enable_deletion_protection = false drop_invalid_header_fields = true idle_timeout = 300 xff_header_processing_mode = "preserve" tags = { Name = "${var.application_name}-alb" } } # -------------------------------------------------------- # Listener # -------------------------------------------------------- # Blue/Greenデプロイ用にそれぞれのlistenerを作成する # http(80, 8080) -> https(443, 8443) にリダイレクトする resource "aws_lb_listener" "blue_https" { load_balancer_arn = aws_lb.alb.arn port = 443 protocol = "HTTPS" ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06" certificate_arn = var.certificate_arn default_action { type = "fixed-response" fixed_response { content_type = "text/plain" message_body = "404: page not found" status_code = "404" } } } resource "aws_lb_listener" "blue_http" { load_balancer_arn = aws_lb.alb.arn port = 80 protocol = "HTTP" default_action { type = "redirect" redirect { port = "443" protocol = "HTTPS" status_code = "HTTP_301" } } } resource "aws_lb_listener" "green_https" { load_balancer_arn = aws_lb.alb.arn port = 8443 protocol = "HTTPS" ssl_policy = "ELBSecurityPolicy-TLS13-1-2-2021-06" certificate_arn = var.certificate_arn default_action { type = "fixed-response" fixed_response { content_type = "text/plain" message_body = "404: page not found" status_code = "404" } } } resource "aws_lb_listener" "green_http" { load_balancer_arn = aws_lb.alb.arn port = 8080 protocol = "HTTP" default_action { type = "redirect" redirect { port = "8443" protocol = "HTTPS" status_code = "HTTP_301" } } } # -------------------------------------------------------- # Listener Rule # -------------------------------------------------------- # Blue/Green x AWS/オンプレごとにリスナールールを作成する # AWS環境へ振り分けるルールは、パスパターン5つまでしか設定できないため、パスパターンの数に合わせてルールを増やす # http(80, 8080)はhttps(443, 8443)にリダイレクトするため、httpsのルールのみを追加すればOK # これらのルールはAWSへ完全移行後に削除します resource "aws_lb_listener_rule" "aws_blue_listener_rule1" { listener_arn = aws_lb_listener.blue_https.arn priority = var.listener_rule_priority1 action { type = "forward" target_group_arn = aws_lb_target_group.blue.arn } condition { path_pattern { values = var.routing_paths1 } } lifecycle { ignore_changes = [action] } tags = { Name = "${var.application_name}-aws-rule1" } } resource "aws_lb_listener_rule" "aws_blue_listener_rule2" { listener_arn = aws_lb_listener.blue_https.arn priority = var.listener_rule_priority2 action { type = "forward" target_group_arn = aws_lb_target_group.blue.arn } condition { path_pattern { values = var.routing_paths2 } } lifecycle { ignore_changes = [action] } tags = { Name = "${var.application_name}-aws-rule2" } } resource "aws_lb_listener_rule" "aws_green_listener_rule1" { listener_arn = aws_lb_listener.green_https.arn priority = var.listener_rule_priority1 action { type = "forward" target_group_arn = aws_lb_target_group.green.arn } condition { path_pattern { values = var.routing_paths1 } } lifecycle { ignore_changes = [action] } tags = { Name = "${var.application_name}-aws-rule1" } } resource "aws_lb_listener_rule" "aws_green_listener_rule2" { listener_arn = aws_lb_listener.green_https.arn priority = var.listener_rule_priority2 action { type = "forward" target_group_arn = aws_lb_target_group.green.arn } condition { path_pattern { values = var.routing_paths2 } } lifecycle { ignore_changes = [action] } tags = { Name = "${var.application_name}-aws-rule2" } } resource "aws_lb_listener_rule" "onpre_blue_listener_rule" { listener_arn = aws_lb_listener.blue_https.arn priority = 100 # 最も低い優先度で設定する action { type = "forward" target_group_arn = aws_lb_target_group.onpre.arn } condition { path_pattern { values = ["/*"] } } tags = { Name = "${var.application_name}-onpre-rule" } } resource "aws_lb_listener_rule" "onpre_green_listener_rule" { listener_arn = aws_lb_listener.green_https.arn priority = 100 # 最も低い優先度で設定する action { type = "forward" target_group_arn = aws_lb_target_group.onpre.arn } condition { path_pattern { values = ["/*"] } } tags = { Name = "${var.application_name}-onpre-rule" } } # -------------------------------------------------------- # Target Group # -------------------------------------------------------- # AWS環境のBlue、Greenおよび、オンプレ環境の3つのターゲットグループを作成する # AWSへの完全移行後にオンプレ環境のターゲットグループは削除する resource "aws_lb_target_group" "blue" { name_prefix = "a-tg1-" port = 80 protocol = "HTTP" vpc_id = var.vpc_id target_type = "ip" health_check { path = var.aws_health_check_path protocol = "HTTP" timeout = 30 interval = 60 matcher = 200 healthy_threshold = 3 unhealthy_threshold = 3 } tags = { Name = "${var.application_name}-aws-albtg1" } lifecycle { create_before_destroy = true } } resource "aws_lb_target_group" "green" { name_prefix = "a-tg2-" port = 80 protocol = "HTTP" vpc_id = var.vpc_id target_type = "ip" health_check { path = var.aws_health_check_path protocol = "HTTP" timeout = 30 interval = 60 matcher = 200 healthy_threshold = 3 unhealthy_threshold = 3 } tags = { Name = "${var.application_name}-aws-albtg2" } lifecycle { create_before_destroy = true } } resource "aws_lb_target_group" "onpre" { name_prefix = "tg-op-" port = 80 protocol = "HTTP" vpc_id = var.vpc_id target_type = "ip" health_check { path = var.onpre_health_check_path protocol = "HTTP" timeout = 30 interval = 60 matcher = 200 healthy_threshold = 3 unhealthy_threshold = 3 } tags = { Name = "${var.application_name}-onpre-albtg" } lifecycle { create_before_destroy = true } } resource "aws_lb_target_group_attachment" "onpre" { for_each = toset(["xxx.xxx.xxx.xxx", "yyy.yyy.yyy.yyy"]) # オンプレ環境WebサーバーのIPアドレス target_group_arn = aws_lb_target_group.onpre.arn target_id = each.value availability_zone = "all" # オンプレ環境のプライベートIPはVPC外にあるためallを指定 port = 80 } output "aws_alb_arn" { value = aws_lb.alb.arn } modules/waf variable "application_name" { type = string description = "アプリケーション名" } variable "allowed_ip_address" { type = list(string) description = "アクセス許可するIPアドレスのリスト" } variable "alb_arn" { type = string description = "作成したALBのARN" } variable "ip_header_name" { type = string description = "接続元IPが格納されているヘッダー名" } resource "aws_wafv2_ip_set" "_" { name = "${var.application_name}-waf-ipset" description = "Allowed ip set for ${var.application_name}" scope = "REGIONAL" ip_address_version = "IPV4" addresses = var.allowed_ip_address } resource "aws_wafv2_web_acl" "_" { name = "${var.application_name}-waf-acl" description = "ACL for ${var.application_name}" scope = "REGIONAL" default_action { block {} } rule { name = "WAFIPsetRule" priority = 1 action { allow {} } statement { ip_set_reference_statement { arn = aws_wafv2_ip_set._.arn ip_set_forwarded_ip_config { header_name = var.ip_header_name fallback_behavior = "MATCH" position = "ANY" } } } visibility_config { cloudwatch_metrics_enabled = false metric_name = "${var.application_name}-waf-ipset" sampled_requests_enabled = false } } visibility_config { cloudwatch_metrics_enabled = false metric_name = "${var.application_name}-waf-acl" sampled_requests_enabled = true } } resource "aws_wafv2_web_acl_association" "_" { resource_arn = var.alb_arn web_acl_arn = aws_wafv2_web_acl._.arn } まとめ AWSへの移行はアプリケーション開発者でインフラリソースの管理をよしなに行い、インフラチームとの調整は最初の導通確認のみで以降はほぼ調整不要でした。今後も調整コストが減り、プロジェクトのコントロールがとても楽になる実感がありました。 「段階的な移行」と言うと関係者が増えてリリース計画が複雑化するため構えてしまう印象がありますが、これであればかなりハードルが下がりますね。AWS強い。

こんばんは。GMOインターネットグループ株式会社の細越と申します。今回はタイトルにある通り、楽曲をカバーする際に効率化できるAI活用方法をご紹介していきます。使用方法というよりかはどういう意図でAIを活用しているかを一例としてみていただければと思います。 イベントでの使用 このはぴば！2024でAIを活用し2曲を4日で制作しました。その際に使用したAIでの効率化についてご紹介します。 アイドル：7:11 ~ / 恋は渾沌の隷也：43:46 ~ https://www.youtube.com/watch?v=5W7-MuaWb2k ①耳コピする（人力） ここに関してはまだまだ人間がやる必要があると思います…。採譜してくれるAIはあるようですがinst制作のようなMIDI等にする必要がある場合は今のところ人間が作業する必要があると感じています。また、イラストや音楽のようなクリエイティブなものに関しては世間の風当たりがまだまだ強いため「作品」という位置付けのものをAIに全て任せることはリスクもあるかと思います。ただ、楽しい作業でもあるので耳がなくなるくらい聴きまくります。 ②パラmixでのAI活用 ①が終わったらいよいよAIの出番です！ここで使用するものは、iZotope社が出している「Neutron 4」です。iZotope様様です。 ※https://www.izotope.jp/jp/products/neutron-4/ より引用 自分のNeutronの使用用途は「mixの土台を作る」ことです。 今まではフェーダーで音量をなんとなく決めてからmixに取り掛かっていたんですが、mix中に「あれ？スネアうるさい？」「ベース小さくない？」と自分の耳を疑い出して沼にハマりフェーダーをいじり出して無限に時間を消費していくことがよくありました。 しかし、Neutronを使用してからフラットに聞くことができmixの時間を大幅に削減することができました。結果、効率良く以降の作業も進めることができています。下記で私がどのようにNeutronを使用しているかご紹介します。 ②-1 Neutronを適用したいトラックにinsertする 適用したいトラック全てにNeutron 4をinsertします。 全てのトラックにinsertしても問題ないと思いますが、自分は重心となっているkickとbass、リバースシンバル等のFX、特徴的に音色のトラックにはinsertしないようにしています。が、kickとbassに関しては「な〜んか違うな〜でも時間もないしな〜」って時に限り挿します。「誤魔化してるわけじゃない…！今はこれが最善なんだ！」と自己暗示をかけながら…。Neutron 4は掛かり具合を自由に調整できるので全部にinsertしても問題はないですが軽いに越したことはないので…。 ②-2 Assistantを押して再生 適用したいトラック全てにinsertしたら上部にあるAssistantを押して楽曲を再生させます。あとは待つだけです。少し待つと解析が完了し画面が切り替わります。 Neutron 3の時は色々事前設定があったんですがそれも不要に！最高。※Visual Mixer的な機能は無くなったわけではないです。 ②-3 サウンドの調整 ここから微調整をしていきます。ここでの調整はあくまでも「土台」。音作りの前段階をイメージして調整します。細かい話になってしまうためざっくり自分が行なっている調整をご紹介します。1つの参考例としてみていただければと思います。 Tone Match まず、初めて全体のトーンの調整をします。ここではリファレンスを聴きなんとなく近い感じになるようにスライダーを調整します。このスライダーはNeutron 4が提案してくれているEQにどれくらい近づけるかどうかを調整する感じかと思います。 「こういうkick感にしたい！」と明確なイメージと単体の音源があれば左の+マークをクリックし読み込みます。読み込みが完了すると左のメニュー「Custom」が読み込んだリファレンスの名前が増えてると思いますのでそちらを選択しスライダーで調整します。※Audiolensを使用している際はここに表示されます。Audiolensについては後述します。 Punch 次にPunchです。実際内部でどんな処理がされているか不明ですが、個人的にはコンプ感を足してくれているものだと思っています。「どうせコンプかけるんだけどな」と思いつつ自分は薄く掛けています。結果的にあとから別のコンプレッサーかけた際より綺麗にかかっているように聞こえます。 Width 続いてWidthです。いわゆるイメージャーです。ただ、ここでのサウンドの広がりを決めるのではなくNeutron 4で広がったように聞こえてしまった音を元に戻す際に自分は使用しています。 Distort ここでは歪み成分を付与できます。自分の場合は別のExciterを使用することが多いのでここはoffかwarmよりのtapeで少しだけ、が多いです。 詳細な音作り もっと詳細に調整、音作りをしたい場合は、Assistantボタンの隣にあるDetailedボタンを押すとそれぞれのモジュールやどの順番でかかっているかなどの詳細が表示されます。この画面で調整していきます。開いた最初はNeutron 4が提案してくれているものが表示されていますので、掛る順番やエフェクトの追加、削除、パラメータの調整などで理想に近づけましょう！ ③マスタリング 最後はマスタリングです。ここでご紹介するマスタリングはinstに対してのものです。上記のイベントは3Dライブのためパラmixが完了した時点で歌声の帯域のスペースを意識しつつマスタリングします。今回の場合厳密に言えばマスタリングという作業ではないかもしれないですが…。もちろん、AIを使っていきます。 ③-1 「Audiolens」でリファレンスを分析 みなさんお馴染みの…と言いたいところなんですが、 まずは下準備をします。その際に使用するのが「Audiolens」です。 ※https://www.izotope.jp/jp/products/audiolens/ より引用 使用方法は簡単です。 1.リファレンスを流す2.「Capture」を押す3.しばらく流したら再度「Capture」を押して保存 これだけです。Audiolensはスタンドアロンで起動させるためDAW内で鳴らす必要はありません。リファレンスを流す際はspotifyやYouTube等で再生させれば大丈夫です。※PCでなっている音全てに反応するため他の音声が鳴っていない状態で再生させてください。 ③-2 Ozone 11 お待たせいたしました。みんな大好き「Ozone 11」のご入場です。 ※https://www.izotope.jp/jp/products/ozone-11/ 引用 ③-3 解析させる 要領はNeutron 4と同じです。Assistantを押して楽曲を再生させます。解析が終わると画面が切り替わります。 ※解析時にmaxilarが追加されるためか一瞬爆音になることがあります。これに限らず爆音出ちゃったときの冷や汗尋常じゃない。 ③-4 リファレンスの適用 解析完了後左の「target」欄の「Custom」をクリックします。すると先ほどAudiolensで聞かせたものが追加されていると思います。 それを選択すると全体がリファレンスに沿ったものに変更されます。 ③-5 調整フェーズ ここまで来たらまたまた調整フェーズです。Ozone 11の適用でイメージ変わってしまった帯域、主張が強すぎる低音と何かしら出てくると思います。Detailedボタンを押して調整していきます。 自分の場合はOzone 11の後に他のプラグインを挿すことが多いためmaxilarはいつも外します。Ozoneも土台作りで使用します。全体の微調整をした後にラウドネスと睨めっこしながらmaxilarやlimiterで最終的な音圧の調整をします。今回はライブ音源のためラウドネスというよりはボーカルを意識して最終調整をしました。 最後に 楽曲制作のAIといえばiZotope。以前までは便利っちゃ便利だけど「う〜ん」みたいなことが多かったですが世界のAIの成長に合わせるようにここ最近の進化がすごいと感じています。クリエイターとしてAIの使用に嫌悪感を抱いている方も多いと思います。ですが、結局は「いいものを作りたい」。これだと思います。「AIのアシストでうまくいった」「AIで削減した時間で別のところに力を入れた」であればいいのではないかなと思っています。色々うまくなっていい作品作りたいぞ〜。おしまい。