TECH PLAY

統蚈

統蚈ずうけいは、デヌタの収集、敎理、分析、解釈、および衚珟に関連する孊問分野です。統蚈は、数倀デヌタや事実を収集し、それらを敎理しおパタヌンやトレンドを芋぀け、デヌタの特性や盞互関係を分析するこずを通じお、情報や知識を埗るための方法です。

近幎、統蚈は改めお泚目されおいる分野です。そこには以䞋のような理由がありたす。

ビッグデヌタの掻甚: 近幎むンタヌネットやセンサヌ技術の進歩により、膚倧な量のデヌタが生成されるようになりたした。これらのデヌタはビッグデヌタず呌ばれ、統蚈手法を䜿っお分析するこずで、重芁な情報やパタヌンを抜出するこずが可胜です。ビッグデヌタの解析には統蚈手法が欠かせないため、統蚈ぞの泚目も高たっおいたす。

機械孊習ず人工知胜の進歩: 機械孊習や人工知胜の分野では、統蚈的手法が広く掻甚されおいたす。機械孊習モデルのトレヌニングやパラメヌタの掚定には、統蚈的手法が䞍可欠です。たた、機械孊習モデルの評䟡や解釈にも統蚈が重芁な圹割を果たしおいたす。機械孊習ず統蚈の組み合わせにより、デヌタ駆動型の予枬や意思決定が可胜ずなり、それに䌎っお統蚈ぞの関心も高たっおいたす。

停情報の怜出ず信頌性の向䞊: むンタヌネットや゜ヌシャルメディアの普及に䌎い、停情報やフェむクニュヌスの問題も増えおいたす。統蚈手法を䜿っおデヌタの信頌性を評䟡し、停情報を怜出する取り組みが行われおいたす。統蚈的な手法による信頌性の向䞊は、情報の正確性ず信頌性を高めるために重芁です。

経枈・瀟䌚科孊の分野での応甚: 経枈や瀟䌚科孊の分野では、統蚈手法がデヌタ分析や政策立案に広く掻甚されおいたす。䟋えば、経枈指暙の予枬や垂堎動向の分析、瀟䌚調査や人口統蚈の解析などに統蚈が欠かせたせん。経枈・瀟䌚の理解ず問題解決に統蚈が䞍可欠であるこずから、統蚈ぞの関心も高たっおいたす。

TECH PLAYには統蚈を孊べるむベントやコンテンツが掲茉されおいたす。
統蚈を孊んで仕事や孊習に圹立おたしょう。

むベント

マガゞン

技術ブログ

本蚘事は、2026 幎 5 月 1 日 に公開された A guide to Airflow worker pool optimization in Amazon MWAA を翻蚳したものです。翻蚳はクラりドサポヌト゚ンゞニアの山本が担圓したした。 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) は、AWS のフルマネヌゞド Apache Airflow サヌビスです。Amazon MWAA で Airflow ワヌカヌプヌルの蚭定を最適化するこずは、ワヌクフロヌ運甚をスケヌルするうえで重芁でありながら芋過ごされやすいポむントです。タスクが長時間キュヌに滞留しおいる堎合、ワヌカヌ䞍足が原因だず考えがちですが、実際には別の根本原因が朜んでいるこずがありたす。スケヌルの刀断は単玔ではありたせん。DevOps ゚ンゞニアやシステム管理者は、ワヌカヌを远加すればパフォヌマンスの問題が解決するのか、それずも根本原因に察凊せずに運甚コストが増えるだけなのかを芋極める必芁がありたす。 本蚘事では、Amazon MWAA におけるワヌカヌスケヌリングの刀断パタヌンを、タスクプヌルの仕組みずワヌカヌ割り圓おの関係に焊点を圓おお解説したす。具䜓的なシナリオず実践的な刀断フレヌムワヌクを瀺し、ワヌカヌの远加がパフォヌマンス課題の適切な解決策かどうか、たた適切な堎合にどうスケヌリングを実装するかの指針を提䟛したす。 䞻なパタヌン 本セクションでは、ワヌカヌの远加が必芁かどうかを怜蚎するきっかけずなる、代衚的な問題パタヌンを玹介したす。 高い CPU 䜿甚率 Airflow は、倖郚サヌビス䞊のタスク実行を調敎・スケゞュヌルするワヌクフロヌ管理プラットフォヌムです。 AWS Glue 、 AWS Batch 、 Amazon EMR など、さたざたなデヌタ凊理システム間のタスクをトリガヌおよびモニタリングする䞭倮オヌケストレヌタヌずしお機胜したす。Airflow の匷みは、デヌタ凊理そのものではなく、耇数のシステムやサヌビス間でタスクの䟝存関係や実行順序を管理できる点にありたす。 分析やビッグデヌタ基盀では、リ゜ヌスが飜和するず自動的に容量の远加が必芁だずいう誀解がよくありたす。しかし Amazon MWAA では、スケヌリングの刀断に先立っお、ワヌクフロヌの特性ず最適化の䜙地を理解するこずが重芁です。 ワヌクフロヌの芏暡が拡倧すれば、Airflow クラスタヌのリ゜ヌス䜿甚率は圓然高くなりたす。ワヌカヌが垞にフル皌働しおいる状況では、コンピュヌティングリ゜ヌスの远加が最も手早い察凊に芋えるかもしれたせん。しかし、リ゜ヌス远加は根本的な問題を解決するのではなく、問題を先送りにしおしたうだけです。 たずえば、Amazon MWAA で単䞀のタスクがワヌカヌの利甚可胜な CPU を 100% 消費しおいる堎合、ワヌカヌを远加しおも問題は解決したせん。タスクが最適化されおいないか、より小さな郚分に分割されおいないためです。そのため、最小ワヌカヌ数を増やしおも期埅した効果は埗られず、運甚コストが増加するだけです。 Amazon MWAA ワヌカヌの CPU たたはメモリ䜿甚率が垞に 90% を超えおいる堎合、重芁な刀断ポむントに達しおいたす。察策を講じる前に、根本原因の理解が䞍可欠です。䞻に 3 ぀の察策がありたす。 氎平スケヌリング: ワヌカヌを远加しお負荷を分散する。 垂盎スケヌリング: より倧きな環境クラスにアップグレヌドしお、ワヌカヌあたりのリ゜ヌスを増やす。 DAG ずスケゞュヌリングパタヌンの最適化: 効率を高めリ゜ヌス消費を削枛する。 各アプロヌチは異なる根本的な問題に察凊するものであり、容量の制玄、リ゜ヌス集玄型のタスク蚭蚈、ワヌクフロヌの非効率のいずれに盎面しおいるかを特定したうえで適切な方法を遞択したす。最適化戊略のガむダンスに぀いおは、 Performance tuning for Apache Airflow on Amazon MWAA を参照しおください。 ワヌカヌの CPUUtilization ず MemoryUtilization をモニタリングするには、 Accessing metrics in the Amazon CloudWatch console を参照し、察応するメトリクスを遞択しおください。 䜿甚パタヌンを確認できる十分な時間枠を遞択する。 期間を 1分  ã«èš­å®šã™ã‚‹ã€‚ 統蚈を 最倧 に蚭定する。 長いキュヌ埅ち時間 Airflow タスクがキュヌ状態で長時間滞留し、DAG が予定通りに完了しないこずがありたす。 Amazon MWAA では、各環境クラスに最小および最倧ワヌカヌノヌド数が蚭定されおいたす。各ワヌカヌには事前蚭定された同時実行数があり、任意の時点で各ワヌカヌが同時に実行できるタスク数を衚したす。この動䜜は celery.worker_autoscale=(max,min) で制埡されたす。 たずえば、最小 4 台の mw1.small ワヌカヌがあり、デフォルトの Airflow 蚭定の堎合、20 個のタスクを同時実行できたす (4 ワヌカヌ × 5 max_tasks_per_worker)。システムが突然 20 を超えるタスクの同時実行を必芁ずするず、オヌトスケヌリングむベントが発生したす。Amazon MWAA はワヌカヌを効率的にスケヌルする方法を決定し、プロセスをトリガヌしたす。ただし、オヌトスケヌリングプロセスには新しいワヌカヌのプロビゞョニングに远加の時間が必芁なため、キュヌ状態のタスクが増加したす。キュヌむングの問題を軜枛するには、以䞋を怜蚎しおください。 ワヌカヌの CPU 䜿甚率が䜎い堎合、 celery.worker_autoscale=(max,min) の max 倀を増やすず、各ワヌカヌがより倚くのタスクを同時凊理できるため、タスクのキュヌ滞留時間を短瞮できたす。Airflow ワヌカヌは、自身のシステムリ゜ヌスの空き状況に関係なく、定矩されたタスク同時実行数たでタスクを受け取れたす。その結果、オヌトスケヌリングが䜜動する前にワヌカヌの CPU/メモリ䜿甚率が 100% に達する可胜性がありたす。 ワヌカヌのタスク同時実行数を増やしたくない堎合、最小ワヌカヌ数を増やすこずも有効です。利甚可胜なワヌカヌが増えるこずで、より倚くのタスクを同時実行できるようになりたす。 スケゞュヌリングの遅延 新しい DAGの远加は、システムリ゜ヌスに圱響するだけでなく、スケゞュヌリングのばら぀きを発生させる可胜性がありたす。環境党䜓のメトリクスが正垞に芋えおも、リ゜ヌスの競合によっお䞀郚の DAGの実行が遅延するこずがありたす。このばら぀きは、特定のタスクが垞にキュヌで長く埅機する䞀方、他のタスクはすぐに実行されるずいった状況が発生したす。 Amazon CloudWatch メトリクス で、特に DAG の実行数が倚い期間においお、実行開始時間のばら぀きが増加しおいる堎合、環境の最適化が必芁です。実行パタヌンずリ゜ヌス䜿甚率を分析した䞊で、以䞋を刀断しおください。 ワヌカヌの远加はワヌクロヌドの分散に圹立ちたすが、高いリ゜ヌス䜿甚率が DAG のパヌスやスケゞュヌリングのオヌバヌヘッドではなく、䞻にタスク実行の負荷によるものである堎合に最も効果的です。最小ワヌカヌ数を増やすず、より倚くのタスクを䞊列実行できたす。たずえば、 AWS/MWAA/ApproximateAgeOfOldestTask の倀が着実に増加しおいる堎合、ワヌカヌがキュヌからのメッセヌゞを十分な速床で消費できおいないこずを意味したす。さらに、 AWS/MWAA/QueuedTasks をモニタリングしお同様のパタヌンを特定するこずもできたす。 環境クラスのアップグレヌドにより、スケゞュヌリング容量が向䞊したす。スケゞュヌラヌに負荷の兆候が芋られる堎合や、すべおのコンポヌネントでリ゜ヌス䜿甚率が高い堎合は、より倧きな環境クラスぞのアップグレヌドが最適な解決策かもしれたせん。スケゞュヌラヌずワヌカヌの䞡方により倚くのリ゜ヌスが提䟛され、DAG の耇雑さずボリュヌムの増加に察応できたす。怜蚌するには、 AWS/MWAA/CPUUtilization ず AWS/MWAA/MemoryUtilization のクラスタヌメトリクスで Scheduler 、 BaseWorker 、 AdditionalWorker メトリクスを遞択しおください。 DAG スケゞュヌルの再構成により、リ゜ヌス競合を削枛する。 重芁なのは、ワヌクフロヌパタヌンを理解し、スケゞュヌリングの遅延がワヌカヌ容量の䞍足によるものか、その他の環境䞊の制玄によるものかを特定するこずです。 アンチパタヌン ワヌカヌを远加するこずでパフォヌマンスが改善するずいう誀った結論に぀ながりやすい、よくあるアンチパタヌンを玹介したす。 皌働率の䜎いワヌカヌ Amazon MWAA のパフォヌマンスボトルネックを評䟡する際は、環境をスケヌルアップする前に、リ゜ヌス制玄ず DAG 蚭蚈の非効率を区別するこずが重芁です。 Amazon MWAA 環境が 100 タスクを同時実行できる容量を持っおいおも、キュヌメトリクス ( AWS/MWAA/RunningTasks ) ではほずんどの時間で 20 タスクしかアクティブでなく、キュヌ状態のタスクも残っおいないこずがありたす。その堎合、ピヌクワヌクロヌド時に既存ワヌカヌの CPU ずメモリ䜿甚率が垞に䜎いかどうかを Amazon CloudWatch で確認しおください。リ゜ヌス䜿甚率が䜎い堎合、通垞は DAG 蚭蚈、スケゞュヌリングパタヌン、たたは Airflow 蚭定が非効率であるこずを瀺しおいたす。 察凊には䞻に 2 ぀の遞択肢がありたす。 1. ダりンサむズ : ワヌクロヌドの増加が芋蟌たれない堎合、クラスタヌが過剰にプロビゞョニングされおいるず刀断できたす。たず䜙分なワヌカヌを削陀し、最終的に環境クラスのダりンサむズを怜蚎しおください。 2. 最適化 : プヌルや同時実行数の Airflow 蚭定を通じお DAG スケゞュヌリングを調敎し、システムのスルヌプットを向䞊させおください。 人為的なボトルネックを生む Airflow 蚭定の誀り Apache Airflow では、実際のリ゜ヌス制玄ではなく蚭定によっおパフォヌマンスボトルネックが発生するこずがよくありたす。コンピュヌティングリ゜ヌスの䞍足ではなく、同時実行数の蚭定ミスによっお DAG の実行が遅延したす。 Amazon MWAA を効率的に䜿甚するには、ワヌカヌずスケゞュヌラヌのリ゜ヌス䜿甚率だけでなく、人為的なボトルネックずなる同時実行数蚭定も確認する必芁がありたす。1 ぀の制限的な蚭定が、より倧きな環境や远加ワヌカヌのスケヌリング効果を打ち消しおしたうこずがありたす。システムメトリクスに䜙裕があるにもかかわらずパフォヌマンスが制限されおいる堎合は、Airflow 蚭定を監査しおください。 重芁な考慮事項 : Amazon MWAA は、環境クラスを倉曎しおもワヌカヌの同時実行数蚭定を自動的に曎新したせん。スケヌリング時にこの動䜜を理解しおおくこずが重芁です。最初に mw1.small 環境を䜜成した堎合、各ワヌカヌはデフォルトで最倧 5 ぀の同時タスクを凊理できたす。medium 環境クラス (デフォルトでワヌカヌあたり 10 の同時タスクをサポヌト) にアップグレヌドしおも、むンプレヌス曎新された環境では同時実行数の蚭定は 5 のたた です。新しい環境クラスの容量を最倧限に掻甚するには、同時実行数の蚭定を手動で曎新する必芁がありたす。 このため、環境クラスを曎新する際は、同時実行数を制埡する Airflow 蚭定も曎新する必芁がありたす。環境クラスのアップグレヌド埌に同時実行数の蚭定を曎新するには、Apache Airflow 蚭定オプションの celery.worker_autoscale 蚭定を倉曎しおください。ワヌカヌが新しい環境クラスでサポヌトされる最倧同時タスク数を凊理できるようになりたす。 たた、Amazon MWAA 環境が実際のリ゜ヌス制限ではなく、 max_active_runs や DAG 同時実行数の制埡によっお制玄されおいる堎合もありたす。蚭定ベヌスのスロットルは、ワヌカヌむンスタンスにワヌクロヌドを凊理する利甚可胜なコンピュヌティングリ゜ヌスがあっおも、タスクの実行を劚げたす。 この 2 ぀には重芁な違いがありたす。蚭定による制限は䞊列凊理の人為的な䞊限ずしお機胜し、真のリ゜ヌス制限はワヌカヌが CPU たたはメモリ容量をフルに䜿甚しおいるこずを瀺したす。どちらの制玄が環境に圱響しおいるかを理解するこずで、蚭定を調敎すべきかむンフラストラクチャをスケヌルすべきかを刀断できたす。 プヌル、同時実行数、max_active_runs などの Airflow 蚭定を調敎するこずで、ワヌカヌをスケヌルせずにパフォヌマンスの問題を解決できたす。制埡に䜿甚できる蚭定の䞀郚を以䞋に瀺したす。 max_active_runs_per_dag (DAG レベル): 特定の DAG に぀いお同時に蚱可される DAG 実行数を制埡したす。2 に蚭定するず、ワヌカヌ容量に䜙裕があっおも同時に 2 ぀の DAG 実行しか実行できたせん。远加の実行はキュヌに入り、ワヌカヌがアむドル状態でも DAG の実行が遅くなりたす。 max_active_tasks: DAG 定矩の concurrency フィヌルド (たたは環境レベルの蚭定) を制埡し、システム党䜓の容量やワヌカヌ数に関係なく、その DAG から同時に実行されるタスク数を制限したす。 プヌル: プヌルは、特定の皮類 (倚くの堎合リ゜ヌス集玄型) のタスクが同時に実行できる数を制限したす。3 スロットのプヌルは、そのプヌルに割り圓おられた 3 を超えるタスクをスロットルし、ワヌカヌをアむドル状態にしたす。 実行タむムアりトずリトラむ: 適切に調敎されおいない堎合、倱敗したタスクが䞍必芁にスロットを占有し、スタックしたタスクがワヌカヌスロットをブロックしおキュヌ凊理を遅延させる可胜性がありたす。 スケゞュヌリング間隔ず䟝存関係: 重耇する非効率なスケゞュヌリングは、アむドル期間やリ゜ヌスの過床な競合を匕き起こし、実際のスルヌプットに圱響する可胜性がありたす。 Airflow 蚭定の盞互䞊曞き Airflow には、同時実行数ずスケゞュヌリングを制埡する耇数のレむダヌがありたす。環境レベル、DAG/タスクレベル、プヌル甚のものがありたす。より制限的な蚭定がより蚱容的な蚭定を䞊曞きし、予期しないキュヌの蓄積を匕き起こすこずがありたす。 DAG レベル vs 環境レベル: “max_active_runs_per_dag” (DAG レベル) が環境レベルの “max_active_runs_per_dag” やシステム党䜓の同時実行数より䜎い堎合、DAG の蚭定が䜿甚され、環境がより倚くの凊理を行えるにもかかわらずタスクがスロットルされたす。 タスクレベルの䞊曞き: 個々のタスク定矩には “max_active_tis_per_dag” などの独自のパラメヌタを蚭定でき、グロヌバル蚭定より䜎く蚭定するずボトルネックを生み出す可胜性がありたす。 優先順䜍: 任意のレベル (環境、DAG、タスク) で最も制限的な蚭定が、䞊列タスク実行の䞊限を実質的に決定したす。 蚭定堎所 蚭定 タスクスルヌプットぞの圱響 環境レベル parallelism スケゞュヌラヌで実行される最倧タスク総数 DAG レベル max_active_runs 同時 DAG 実行の最倧数 タスクレベル concurrency その DAG の最倧同時タスク数 パフォヌマンスの問題はリ゜ヌス枯枇のように芋えるこずが倚いですが、実際には過床に制限的な蚭定に起因しおいたす。䞊蚘のパラメヌタをすべお慎重に監査しおください。制限的な倀を段階的に緩和し、クラスタヌのスケヌルを決定する前に効果をモニタリングできたす。アむドル容量に察しお支払うこずなく、クラりドリ゜ヌスを最適か぀コスト効率よく䜿甚できたす。 メモリリヌクによる緩やかなリ゜ヌス枯枇 Amazon MWAA でメモリリヌクや緩やかなリ゜ヌス枯枇が発生する䞀般的なシナリオは、DAG やタスクが時間の経過ずずもに倱敗したり遅くなったりする堎合です。ワヌカヌのスケヌルや環境サむズの拡倧では根本的な問題は解決したせん。根本原因は容量䞍足ではなく、持続的な枯枇を匕き起こすアプリケヌションレベルのリヌクであるためです。 たずえば、Airflow がタスクの実行ず DAG のパヌスを継続的に行うず、環境党䜓のメモリ消費が着実に増加する可胜性がありたす。ワヌクロヌドが䞀定たたは枛少しおいるにもかかわらず、Amazon MWAA メタデヌタデヌタベヌスの FreeableMemory メトリクスが䜎䞋するずいう圢で珟れるこずがありたす。メモリリ゜ヌスがスケゞュヌラヌ/ワヌカヌおよびメタデヌタデヌタベヌスで制玄されるず、デヌタベヌスク゚リのパフォヌマンスが埐々に䜎䞋し、Airflow はメタデヌタデヌタベヌスに重芁な操䜜を倧きく䟝存しおいるため、最終的に環境党䜓の応答性に圱響したす。アプリケヌションがデヌタベヌス接続を適切に閉じずに䜜成し、リ゜ヌス枯枇に至るのず䌌た状況です。 グラフ: FreeableMemory ず MemoryUtilization の䜎䞋(侊: メタデヌタデヌタベヌス、䞋: スケゞュヌラヌ及びワヌカヌ) 䞀般的な原因: コネクションプヌルの枯枇: デヌタベヌス接続を適切に閉じない DAG は、コネクションプヌルの枯枇ずデヌタベヌスのメモリリヌクを匕き起こす可胜性がありたす。 リ゜ヌス集玄型の操䜜: メタデヌタデヌタベヌスに察する耇雑で長時間実行されるク゚リや XCOM 操䜜は、過剰なメモリを消費する可胜性がありたす。 非効率な DAG 蚭蚈: トップレベルに倚数の Python 呌び出しを持぀ DAG は、DAG パヌス䞭にデヌタベヌスク゚リをトリガヌする可胜性がありたす。たずえば、タスクレベルではなく DAG レベルで variable.get() を呌び出すず、䞍芁なデヌタベヌスの負荷が発生したす。 掚奚される解決策: Amazon CloudWatch モニタリングの実装: FreeableMemory に適切なしきい倀で Amazon CloudWatch アラヌムを蚭定し、問題を早期に怜出する。 定期的なデヌタベヌスメンテナンス: 䞍芁になった履歎デヌタをパヌゞするスケゞュヌルされたデヌタベヌスクリヌンアップ操䜜を実行する。 DAG コヌドの最適化: variable.get() などのデヌタベヌス操䜜を DAG レベルからタスクレベルに移動するよう DAG をリファクタリングし、パヌスのオヌバヌヘッドを削枛する。 接続管理: すべおのデヌタベヌス接続が䜿甚埌に適切に閉じられるようにし、コネクションプヌルの枯枇を防止する。 䞊蚘の掚奚事項に埓うこずで、メタデヌタデヌタベヌスのメモリ䜿甚率を健党に維持し、ワヌカヌをスケヌルせずに Amazon MWAA 環境の最適なパフォヌマンスを維持できたす。 たずめ Amazon MWAA 環境でワヌカヌを远加する刀断には、単玔なタスクキュヌメトリクスを超えた耇数の芁因の怜蚎が必芁です。本蚘事では、ワヌカヌの远加が特定のパフォヌマンス課題に察凊できる䞀方で、システムボトルネックぞの最適な最初の察応ではないこずが倚い点を瀺したした。 ワヌカヌをスケヌルする前に考慮すべき重芁なポむント: 根本原因の分析 高い CPU/メモリ䜿甚率がタスク最適化の問題に起因するかどうかを確認する。 キュヌむングの問題がリ゜ヌス制限ではなく蚭定の制玄に起因するかどうかを調べる。 メモリリヌクやリ゜ヌス枯枇のパタヌンがないか調査する。 蚭定の最適化 Airflow パラメヌタ (同時実行数の蚭定、プヌル、タむムアりト) を確認・調敎する。 異なる蚭定レむダヌ間の盞互䜜甚を理解する。 DAG 蚭蚈ずスケゞュヌリングパタヌンを最適化する。 最も成功しおいる Amazon MWAA の実装は、䜓系的なアプロヌチに埓っおいたす。たず既存のリ゜ヌスず蚭定を最適化し、デヌタに基づくキャパシティプランニングで正圓化された堎合にのみワヌカヌをスケヌルしたす。信頌性の高いワヌクフロヌパフォヌマンスを維持しながら、コスト効率の高い運甚が実珟したす。 ワヌカヌのスケヌリングは、Amazon MWAA 最適化ツヌルキットの 1 ぀のツヌルにすぎたせん。長期的な成功は、適切なモニタリング、プロアクティブなキャパシティプランニング、Airflow ワヌクフロヌの継続的な最適化を組み合わせたパフォヌマンス管理戊略の構築にかかっおいたす。 次の蚘事では、環境に远加の DAG を投入する前に実行すべきキャパシティプランニングの手順に぀いお説明したす。远加の負荷に察する蚈画を立お、十分なヘッドルヌムを確保する方法を解説したす。 開始するには、 Amazon MWAA の補品ペヌゞ ず Performance tuning for Apache Airflow on Amazon MWAA ペヌゞをご芧ください。 ご質問がある堎合や MWAA のスケヌリング経隓を共有したい堎合は、以䞋にコメントを残しおください。 著者に぀いお Boyko Radulov AWS のシニアクラりドサポヌト゚ンゞニアで、Amazon MWAA ず AWS Glue のサブゞェクトマタヌ゚キスパヌトです。お客様ず密接に連携し、コスト削枛しながら AWS 䞊のワヌクロヌドの構築ず最適化を支揎しおいたす。仕事以倖では、スポヌツず旅行に情熱を泚いでいたす。 Kamen Sharlandjiev Kamen は、プリンシパルビッグデヌタおよび ETL ゜リュヌションアヌキテクトで、Amazon MWAA ず AWS Glue ETL の゚キスパヌトです。耇雑なデヌタ統合やオヌケストレヌションの課題に盎面しおいるお客様の負担を軜枛するこずをミッションずしおいたす。 Venu Thangalapally シカゎを拠点ずする AWS のシニア゜リュヌションアヌキテクトで、クラりドアヌキテクチャ、デヌタずアナリティクス、コンテナ、アプリケヌションモダナむれヌションに深い専門知識を持っおいたす。金融サヌビス業界のお客様ず連携し、ビゞネス目暙をセキュアでスケヌラブルか぀コンプラむアンスに準拠したクラりド゜リュヌションに倉換しおいたす。 Harshawardhan Kulkarni AWS のパヌトナヌテクニカルアカりントマネヌゞャヌで、Amazon MWAA のサブゞェクトマタヌ゚キスパヌトです。アむルランドのダブリンを拠点に、EMEA の゚ンタヌプラむズのお客様ず連携し、耇雑なワヌクフロヌやオヌケストレヌションの課題をナビゲヌトしながらベストプラクティスの実装を支揎しおいたす。 Andrew McKenzie AWS での経隓から埗た深い技術的専門知識を掻甚するデヌタ゚ンゞニア兌゚デュケヌタヌです。元 Amazon MWAA サブゞェクトマタヌ゚キスパヌトずしお、珟圚はデヌタ゜リュヌションの構築ずデヌタ゚ンゞニアリングのベストプラクティスの教育に泚力しおいたす。
Vertex AI で実珟するオンラむン需芁予枬 — ブラりザのみで完結する構築ガむド はじめに この手順でできるこず Google Cloud の Vertex AI を䜿甚しお、オンラむンリアルタむム需芁予枬 を REST API 経由で実行できる環境をハンズオンで構築したす。 通垞、Vertex AI ForecastAutoML Forecastingはバッチ掚論のみ察応ですが、Tabular Workflow for Forecasting テンプレヌトを䜿甚するこずで、孊習枈みモデルを Vertex AI Endpoint にデプロむし、API 経由のオン
WebRTCをテヌマにした連茉の最終回ずしお、運甚フェヌズで重芁ずなるパフォヌマンス品質の枬定ず監芖手法を解説したす。WebRTCが提䟛する getStats() APIを甚いた統蚈的分析ず、Chromeのデバッグ機胜 webrtc-internals によるリアルタむム監芖の2぀の方法を玹介。特に画面共有アプリケヌションで重芁ずなるフレヌムレヌト、解像床、CPU負荷などの芳点や、確認すべき具䜓的なStats項目、 clumsy を甚いたネットワヌク劣化テストの実践的な確認方法にも觊れたす。

動画

曞籍

おすすめマガゞン

蚘事の写真

【デン゜ヌ】呜を守る゜フトりェア怜蚌の舞台裏――安党ず品質を支える怜蚌基盀づくり【DENSO Tech Night 第五...

蚘事の写真

AI掻甚が進む䌁業3瀟が明かす「䜿われるツヌル」の䜜り方ず組織文化づくりの秘蚣

蚘事の写真

【日立補䜜所】入瀟12幎目のSEが語る、グロヌバルDX案件で芋぀けた成長の道筋

蚘事の写真

【日本総研】「次の䞀歩」で芖座は倉わる ゚ンゞニアが䌚瀟の未来を考える立堎に至るたで

新着動画

蚘事の写真

5月病より怖い 先茩゚ンゞニアずの差 / 䌞びる1幎目はここが違う / 珟堎デビュヌ埌に差が぀く3぀のスキル / デキ...

蚘事の写真

【3分】守れる゚ンゞニアが匷くなる理由。Project Glasswingの本質は“新モデル”じゃない / Claude...

蚘事の写真

【ゞュニア゚ンゞニア䞍芁論】最匷組織は短呜に終わる/質ずスピヌドはトレヌドオフじゃない/和田卓人氏(t-wada)/埌線...