Perl の記事一覧

Perlを中心としたIT関連カンファレンス「YAPC::KYOTO- 2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『4PB（ペタバイト）を超えるオブジェクトストレージをハードウェアからアプリケーションにかけて運用するノウハウ』をお届けします。 登壇者 三上 烈史（みかみ つよし）　@rsym1290GMOペパボ株式会社 技術部プラットフォームグループ https://speakerdeck.com/rsym1290/4petabaitowochao-eruobuziekutosutoreziwo-hadoueakaraapurikesiyonnikakete-yun-yong-surunouhau 30days Albumを支えるオブジェクトストレージ 三上が今回のテーマとして取り上げるのは、写真共有サービス「30days Album」とプライベートなオブジェクトストレージ「Bayt」です。 GMOペパボでは、独自にオブジェクトストレージを保有しており、複数のサービスで活用しています。一般的なサービスでオブジェクトストレージを利用することも多くなっていますが、自らオブジェクトストレージを作って運用することになるという例はなかなかないのでは、と三上は話します。そうしたことから、どのようにオブジェクトストレージを構築して運用してきたのか、そのノウハウも含めて紹介されました。 GMOペパボのサービス内で、特にオブジェクトストレージが重要な役割を果たしているのが、30days AlbumとBaytという2つのサービスです。この2つのサービスには密接な関係があります。 GMOペパボの提供するサービス一覧。この中でも特にオブジェクトストレージを活用しているのが30days AlbumとBaytです。 低コストの自前オブジェクトストレージ 30days Albumは、撮影した写真や動画をアップロードして共有できるアルバム形式のサービスで、パスワードではなく「合い言葉」という形で認証して共有できます。2008年にスタートしたサービスで、2023年3月16日の時点でおよそ8.7億枚の写真を保管しているそうです。 30days Albumは写真や動画の共有サービス。約8.7億枚の写真を保管しています。 Baytは、GMOペパボ独自のプライベートなオブジェクトストレージです。GMOペパボの各サービスがアップロード先として利用していて、S3互換であることが特徴の1つです。AmazonS3で利用できるGetObjectやPutObjectといった一部のAPIを実装していて、S3と同じような感覚で利用することができるようになっています。 BaytはS3互換のプライベートなオブジェクトストレージ GMOペパボでは、ECサイト作成支援「カラーミーショップ」で商品画像のアップロード先や、ホームページ作成サービス「グーペ」のコンテンツのアップロード先などで利用されています。 S3やGCS（Google Cloud Storage）といった既存のオブジェクトストレージを使わずに、なぜわざわざ自前で開発しているかというと、その理由として30days Albumの運用を通じて培った知見とコストが関係していると三上は説明します。 前述の通り30days Albumのスタートは2008年。サービスの特性上、オブジェクトストレージが必要になるので、まずはPerl製のMogileFSを使ってオブジェクトストレージを構築しました。その後、2015年頃になると、カラーミーショップなどほかのサービスを含めて事業規模が拡大し、各サービスでもオブジェクトストレージのニーズなどが高まってきたそうです。 当初はOpenStack SwiftやS3を使うといった案があったものの、最終的にはS3互換のAPIを実装することでオブジェクトストレージ提供することにしたそうです。理由としては、この時点で30days Albumで7年間かけて自前のオブジェクトストレージで運用した実績があり、コストがかからない、実装の手間が削減できる、運用も安定する、という点があったそうです。 こうして生まれたのがBaytで、それまでサービスごとにストレージが異なっていたのを、統一されたオブジェクトストレージに統合できるようになりました。 とはいえオブジェクトストレージをBaytだけに限定したわけではなく、コストを重視するならBayt、機能を重視するならS3／GCSという使い分けになっています。最低限のオブジェクトストレージの機能でアップロードするだけでいい場合などはBayt、それで機能が足りなければS3などを使うという形になっているとのこと。 MogileFSとBaytの構成 BaytのベースとなったMogileFSは、スケーラブルな分散ストレージを構築できるOSSで、4つの要素で構成されています。 client：リクエストを発行するtracker：クライアントからのリクエストを受け付けるdatabase：オブジェクトの保存場所やストレージを構成するサーバー・デバイスの情報を格納したデータベースstorage node：実際にオブジェクトが格納される場所で、GMOペパボではC言語で実装されたcmogstoredを利用 MogileFSのアーキテクチャ。4つの要素から構成されています。 続いて30days Albumに当てはめた構成について説明されました。前段階としてユーザーが利用するフロントエンドとしてのアプリケーションがあり、アップロードされた画像のサムネイルを作成するなどの画像処理のためのサーバーがあります。続いて30days Album用のAPIがあり、これが「client」に相当します。 さらにtrackerやdatabase、storage nodeが存在しており、storage nodeではたくさんのHDDを並べてストレージサーバーが構築されています。 30days Albumの構成図 Baytの場合、MogileFS運用の知見をそのまま生かすため、こうした構成をそのまま利用しました。ここに、Baytとして必要なアプリケーションやフロントのリバースプロキシなどを追加して実装しています。 さらにバックエンドをそのままにBaytを追加しています つまり、フロントは分かれているけれどもバックエンドは共有されているということで、物理的には30days AlbumとBaytのそれぞれのオブジェクトが混在している形になっています。1つのHDDの中に30days Albumでアップロードされた画像も、Baytにアップロードされたコンテンツが保管されているわけです。 ここでMogileFSのドメインという仕組みを利用して、あるオブジェクトが30days Album、カラーミーショップなどのいずれに属しているかを論理的に区別しています。また、複数のストレージサーバーを構成していることで、HDDが1つだけでなくストレージサーバー自体が1つ壊れても復旧できるよう冗長性も確保しています。 30days AlbumとBaytのオブジェクトはバックエンドで共有化されていて混在していますが、ドメインの仕組みによって論理的に区別されています ハードウェアはやみくもに増やせない、その3つの課題 続いて三上はハードウェアに関して取り上げます。S3やGCSのようなクラウド全盛時代になると、ハードウェアを意識することは少なくなってきます。しかし、クラウドを支えているのはハードウェアなので、運用側は意識する場面があると三上は話します。 GMOペパボの場合、ストレージサーバーとして15台を運用しており、その中にHDDが386本存在（3月16日時点）。総容量は4.58ペタバイトという容量になっています。しかもこうした容量は常に増え続けるため、十分な容量を常にキープし続ける必要があります。そのため、大容量HDDを確保して増設していくことになります。 ストレージサーバーの台数は15台、HDDは386本となり、総容量は4.58ペタバイトに達しています しかし、やみくもにただ増設すればいいというわけではないと三上は指摘します。そこにある課題は3つです。 サーバーラックは無尽蔵に増やせない基本的にはサーバラックは月額払いでの契約が一般的で、「データセンターにもよりますが、1ラックで月額20～30万円」と三上は言います。ラックの追加もむやみにできるわけではなく、サーバラックを増やせば増やすほど運用コストも上がります。サーバーもHDDも寿命があるハードウェアはいずれ壊れるものです。HDDが壊れればストレージ総容量が減るし、それを見据えた増設が必要です。壊れたあとの対処は大変なので、できれば壊れる前に廃棄するのが理想です。サーバーの性能は相対的に劣化するハードウェアに関する技術は日々進歩しており、年々より高性能なサーバーが登場します。こうしたサーバの登場により、導入した当時のサーバは時間の経過に伴い相対的に性能面で劣ることになります。また、サービスを長年運用するとサービスが成長し、導入当時の性能だけではいずれ耐えきれなくなることが考えられます。そのため、単にサーバーを導入すればいいというわけではないと三上は言います。 こうした課題に対して三上は、「ライフサイクルを意識したハードウェアの運用が必要」と指摘します。 ライフサイクルを意識して4ペタバイトまでストレージを運用 GMOペパボでは、ストレージサーバーの帯域や容量のライフサイクルを作って運用しています。 例えばサーバーラックに3台のストレージサーバーがあり、HDDが288TBの容量だった場合に、6TB×16ベイのサーバーを1つ廃棄すると、容量は192TBに減少します。しかし、ラックのスペース自体は確保できるので、容量の大きいより良いストレージサーバーを導入することができます。例えば18TB×16ベイのストレージサーバーを増設すると、トータル容量も480TBに拡大できます。 ストレージサーバーの増設・退役のライフサイクルを意識することが重要です サーバーの選定も重要です。オブジェクトストレージは容量が命なので、1U、2Uといったサーバーのサイズの中でどれだけHDDを搭載できるかが重要になります。GMOペパボでは、2Uサイズで16ベイのHDD、または4Uで36ベイのHDDを搭載したサーバーを中心に利用していると三上は説明。 30days AlbumとBaytの運用経験から、cmogstoredはCPUやメモリの性能はそれほど求められていないということが分かり、サーバーを選択しやすいというメリットもあるそうです。30days AllbumとBaytでは、CPUはインテル Xeon Bronze系、メモリは8GB程度であれば運用可能とのことです。 HDDはデータセンター向けの製品を採用。常時稼働が前提なので耐久性の高いものを選択しています。保証期間も3～5年の保証期間で利用できるため、データセンター向けHDDが基本になります。 ちなみに、1ドライブ当たりのデータ容量が大きく、容量単価が安いという点からSSDではなくHDDを採用しているそうですが、Baytの要求水準からすると、IO性能はHDDでも十分とのことでした。 三上は余談といいつつ、ここ最近の半導体不足の影響を受けてストレージサーバーの納期が延びている点を指摘します。今までは2カ月程度だった納期が、在庫がない場合は半年から1年先になってしまっているそうで、納期から逆算した発注計画が必要だと言います。 為替もインパクトがあり、海外製サーバーを採用した場合に円安の影響を受けやすい点も課題です。前年の段階で予算計画を立てても、為替の変動で想定していたサーバー構成だと予算オーバーしてしまう場合もあるため、こうしたリスクもあるとのことです。 こうして運用していくストレージサーバーですが、ハードウェアの寿命があるため最終的には退役、廃棄までが運用になります。壊れてからでは遅いので、壊れる前に退役・廃棄をして、それによって新しいストレージサーバーを入れられるようになります。 とはいえ、HDDが急に壊れてしまうことはあるので、その対策も必要になります。GMOペパボではsmartmontoolsを利用したHDDの監視を行っています。これによって不良・故障を検知しており、問題を検知すると自動でメールが送信されます。これを使って自動でissueを立てるという仕組みになっているそうです。 壊れたHDDの切り離しはMogileFSの機能を利用。MogileFSではHDDを5つのステータスで管理しており、切り離す場合にはdeadフラグを設定して使用できなくします。保存されているデータは冗長構成で他のドライブにも保存されており、MogileFSは切り離しでHDDが減っても、冗長性を維持するよう自動でレプリケーションをやり直してくれるという機能もある点も特徴です。 こうして運用した結果、4PBを超える容量に達したオブジェクトストレージ。実際の利用状況を見ながら、使用量を上回るHDD容量を維持し続け、その中で退役や廃棄を行ってきていたそうです。 リアルタイムで計測してきたというストレージ容量。実際の使用量である赤線が総容量の青線に達しないように運用を続けており、退役で一時的に容量が減っても右肩上がりに容量が上がっています。 BaytにおけるS3 REST APIの実装例 前述の通り、BaytはS3のREST APIを一部導入したオブジェクトストレージです。S3のAPI Referenceに従って実装したREST APIを備えていますが、すべてのAPIやオプションではなく、頻繁に利用されるAPIに限定していて、オプションも必要最低限に絞っています。基本的にはS3と同じようにBaytを利用できるという形になっています。 Baytに実装されているREST API 実際の実装では、MogileFSをバックエンドとして、BaytはRuby on Railsで実装、フロントにREST APIが提供されているという構成です。GetObjectを例にすると、まずはBaytのAPIにリクエストが送信されたのちに、APIがデータベースを参照してオブジェクトのコンテンツタイプやファイルサイズなどのメタデータを取得します。 このデータベースはMogileFSとは別に用意してあり、同時にMogileFSに対してオブジェクトの格納先の問い合わせが行われます。その格納先が抽出されると、そのパスが返ってきたらリバースプロキシが実際のオブジェクトを取得してレスポンスとして返す、という流れになります。 BayではMogileFSをバックエンドとしたREST APIを実装しています Baytの構成図に当てはめるとこのような構成になっています BaytはS3へ、30days Albumもハイブリッドに 実はBaytは、今後S3へ移設することを予定しています。コストを重視したBaytを採用してきましたが、2015年以来サービスが成長を続けており、予算をさらにかけてより機能面を重視しようという方向になってきたといいます。すでにグーペではS3への移管が完了しているとのこと。しかし、30days Albumに関しては同様の運用を継続する方針です。 とはいえ、まだ課題があると三上は話します。1つ目が運用の属人化で、これまで説明してきたハードウェアのライフサイクルの運用やMogileFSに関しても、詳しい人間が限られていて、その人間に運用が集中しているそうです。 対策としては、SREとして運用のtoil削減や自動化による運用負担の軽減を模索。ドキュメントを充実させるほか、オンコールトレーニングによる障害対応力の向上を図ります。こうした話は、同じYAPCにおけるGMOペパボ技術者の講演（https://developers.gmo.jp/31489/）でも話していた内容です。 また、2008年からという長いサービスであるがゆえに、30days Albumのサービス全体がレガシー化しているというのも課題で す。30days Albumは、ストレージ以外の部分もオンプレミス中心の設計になっており、ストレージ以外のハードウェアも管理しなければならないため、これをクラウドとのハイブリッドにすることでハードウェアの運用負荷の軽減を図りたい考えです。 最後にYAPC::Kyoto 2023の写真を30days Albumへぜひ投稿してくださいという挨拶で締めくくられました。アルバムは実際に https://30d.jp/yapcjapan/5 で公開されているのでぜひご覧ください。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=vO5CbCpJ9_g

Perlを中心としたIT関連カンファレンス「YAPC::Kyoto  2023」が3月19日に京都市の京都リサーチパークで開催されました。Perlに限らないさまざまな技術情報が満載のイベントです。今回は「try/catch」をテーマにしたということで、初めて現地とオンラインというハイブリッドでの開催となりました。GMOインターネットグループからは、GMOペパボの技術者が参加して講演を行いました。今回はその講演から『入門 障害対応 「サービス運用はTry::Catchの繰り返しだよ、ワソン君」』をお届けします。 登壇者 渡部 龍一　@ryuichi_1208GMOペパボ株式会社 技術部プラットフォームフォームグループ SRE https://speakerdeck.com/ryuichi1208/ru-men-zhang-hai-dui-ying GMOペパボの古参サービスを支える技術部プラットフォームグループ 今回講演した渡部が主に担当しているサービスは、ネットショップ作成・運営のためのプラットフォームである「カラーミーショップ」です。2005年にサービス提供を開始した古参サービスで、流通総額は1兆円を超え、比較的大きなトラフィックを有するサービスです。 カラーミーショップのサービスの特徴やサービス構成は、「CI/CD Conference 2023 by CloudNative Days」（https://developers.gmo.jp/30849/）でもご紹介しているので、そちらも参考にしてください。 そんなカラーミーショップをはじめとしたGMOペパボのサービスにおいて、渡部が所属する技術部プラットフォームグループが担当しているのは、「サービスの多様性を確保し、サービスの成長に合わせて適切な環境を提供する」という点だと渡部は言います。具体的にはサーバーの調達、キッティング、SREによるサービスレベルの向上、クラウド環境の検証や選定、専門事業部門のアプリケーションの改善・開発など、事業の成長を支えることを目指しています。 障害対応における5つのフェーズ そんなGMOペパボにおける障害対応フローが今回のテーマです。 渡部はまず、サービス障害の定義として「通常の運用状態から逸脱してユーザーに影響を与える事象」と位置づけます。これはシステムの異常動作やアプリケーションの問題などが該当します。 それに対する「障害対応」とは、「サービス障害が起こった状態から通常の運用状態に戻すための対応」ということになります。 この障害対応を、渡部は5つのフェーズに分類します。 （1）障害の影響範囲の特定と分類 まずは提供範囲の特定が重要になります。使えない機能は何か、例えば外形監視が落ちている場合はどこに影響があるかを評価し、分類します。その結果、問題解決に必要な情報を集めることができ、影響範囲が分かれば、原因特定の方針決定の根拠となる情報も得られると言います。 （2）関係者への連絡 続いて、ユーザーに対してどのような影響があるのかを、関係者に周知することが重要だと渡部は指摘します。障害発生時は技術的な話をしがちですが、最初にやるべきはユーザーへの影響がどの程度あるかを共有することで、「報告は結論ファーストを意識している」と渡部。 同時に、サービスに関わる様々なチームへの連絡も行います。渡部の所属するSREチーさまざまは障害アラートなどを出しますが、障害の復旧がすべてできるわけではありません。そのため、マネージャーやカスタマーサポートチームに連絡して協力を仰ぐこともあるそうです。エンドユーザーに対して影響がある障害であれば、SNSなどでのアナウンスも必要になるので担当者と共有をします。 障害を起こしたアプリケーションに精通しているメンバーが、常に障害のアラートを受け取れるわけではないため、その場合はアプリケーションエンジニアに、セキュリティインシデントならセキュリティエンジニアにエスカレーションすることもあるそうです。 （3）原因調査 3番目が「なぜ繋がらないのか」を調べるフェーズです。「外形監視になった」、「Webサービスに繋がらなくなった」というだけでは、「なぜ繋がらないのか」の原因は分かりません。 最も頻度が多いのは、サービスに何かしらの変更を加えた際に繋がらなくなるエラーが起きることだと言います。そのため、まずは変更したシステムを調べることになります。 例えば、アプリケーションをデプロイした場合はその内容を確認したり、GUIの設定画面からサーバーの設定を変更していたらそれを確認したりします。とはいえ、「何もしていないのに壊れるケースが"たまによくある"」と渡部は苦笑します。 他にはハードウェアが原因の場合や急激なトラフィックでソフトウェアが耐えきれない場合があるので、もう少し詳しく原因を探っていくそうです。サービスを構成するコンポーネントから、怪しい部分を探るわけです。 原因調査は、仮説確認を繰り返していくフェーズだと渡部は話します。どこが怪しいのか全くわからない状いであれば、例えば構成図を見てロードバランサーやWebアプリケーション、データベース、ネットワーク、外部連携サービスなど、何かおかしくなっていないかを見ていきます。 渡部が取る手法としては「挟み撃ち法」があるそうです。これは、例えばL3レイヤーを調べたらL7のWebアプリケーションを確認し、L4を見てL6を見る、というような順番で確認していく方法です。「OSI参照モデルをイメージしてもらえれば分かりやすい」と言います。 このフェーズではログ調査も行って、怪しいログをチェックすることもしています。 （4）復旧作業の実施 原因が判明したら復旧作業を実施します。これには2つのパターンがあり、一つ目が「根本対応」です。調査で原因が完全に判明すれば根本的な対応が行えます。ところが、原因は分からないけれども接続できないということもあります。 そうした場合に行うのが「止血対応」と呼ばれる作業です。過去の知見から、「もしかしたら復旧するかもしれない」という対応手段を試していくというものです。ここで大事なのが、「原因が分からなくてもユーザーが正常にサービスを利用できる」ことを最優先にするということです。そのため、まずは止血対応によってサービスを正しい状態にすることを意識しているそうです。 具体的な手法としては、OSやミドルウェアの再起動、アップデートをしていたら根本原因が分からなくてもロールバックするといった手段で復旧を試みます。急激なトラフィック増加等があればリソース不足の可能性もあるので、スケールアウトなどの対応をします。 （5）ポストモーテム 最後のフローがポストモーテムです。これは障害対応後に行われる反省と改善のための分析会議」で、障害の原因、障害対応の振り返りを行うことで、今後の改善点を見つけることを目的としています。 こうした会議でありがちなのが、失敗の要因を明確にすることだけになってしまい、成功の要因が明らかにならないという例があります。そこで渡部は「対応がなぜうまくいったのか」という要因を分析してドキュメント化も行っているそうです。 この会議のドキュメントは、会議に未参加のチームや、今後参画する新メンバーも学んでいけることを意識して執筆していると言います。具体的にはなぜこうした対応をしたのか、障害復旧後にアクションアイテムがあったらイシュー化して追跡しやすくする、といった記録を残していると言います。 1人に頼らずメンバー全員の能力向上を こうした障害対応の能力をどのように向上させるか。渡部はまず「障害対応能力」について、前述の5フェーズを全て1人で担当できるという人物が能力値マックスと規定します。 そもそも障害をゼロにすることはできないという判断から、障害が発生したときに対応するメンバーの能力向上が必要というのが渡部の考えです。そのためには「何度でも障害に向き合っていく必要がある」と渡部は言います。 以前まで、GMOペパボでも障害発生時に一部の優秀なエンジニアが1人で原因特定から復旧までを短時間で対応してしまい、他のメンバーの知見が残らないということがあったそうです。 そういった優秀なエンジニアも24時間365日稼働できるわけではないので、そのエンジニアがいないときの障害対応の時間が長くなってしまい、サービスの信頼性低下にも繋がりかねません。 そのため、障害対応能力が高いメンバーがチーム内に多く存在するほど、サービスの信頼性向上に繋がる、というのが渡部の考えです。 そうしたメンバーを増やすためには、障害対応の教科書のような書籍を学習するだけで実践するのは難しいといいます。例えばサービスの再起動をするためのコマンドは学べても、どのタイミングで、どういった根拠で再起動をするのか、といった見極めは経験が必要だからです。もちろん、本番環境で学ぶのが一番なのですが、それが難しい場合もあります。 2つの施策で能力向上 渡部が採用した施策は2つ。Playbookの作成と障害対応訓練です。 Playbookとはアメリカンフットボールの用語で、戦略やプレイをまとめた資料です。渡部は「一定の知見や経験を持った人でなければ理解できない熟練者向けのドキュメント」と位置づけます。渡部のチームでは、障害対応能力の高いメンバーが行った作業内容と、その作業に至った思考の流れをドキュメント化しているそうです。 これまでのドキュメントには事実は記載されていましたが、具体的な対応方法の記載がありませんでした なぜそのコマンドを打ったのか、なぜその作業を行ったのか、結果として何が起きたのか、そういった部分を取りまとめることで、他のメンバーの障害対応能力向上に繋がると考えたと言います。 PlaybookはMarkdownによって事例ごとに情報を蓄積していきます こうしてPlaybookに事例を積み上げて情報を共有し、メンバーのノウハウを蓄積していくことに加えて、障害対応経験を増やすための訓練も行います。 過去に発生した障害などをテスト環境に再現して、実際に調査から復旧までを実践してもらう内容ということで、さらに出題者と回答者に分かれて実施しているそうで、机上演習のようなものというイメージのようです。 Playbookと障害対応訓練という施策を実施した結果、「チーム全体の障害対応能力の向上に繋げることができた」と渡部は言います。調査から復旧までを単独で実施できるメンバーも増えているそうです。訓練で実施したトレーニングと同じ障害が、訓練の数時間後に実際に発生する、といったこともあったそうで、訓練を生かすこともできたと言います。 障害対応も一日にしてならず 「障害を完全になくすことはできない」。まとめとして渡部はそう伝えます。そのため、障害は起きるものとして対応に向き合う必要があります。優秀なメンバーだけが対応するような属人的な状況は危険で、障害対応できるメンバー数を可視化していく必要があるとしています。 障害対応できるメンバーを増やすためのPlaybookや障害訓練といった施策も、すぐに効果が出るような施策ではなく、渡部は「ローマは一日にしてならず、障害対応も一日にしてならず」として、継続的に続けることが必要だと強調しました。 質疑応答では、Playbookを作成するためのコストの問題について問われ、渡部は「コストはかかるけれど、最終的にメンバーが増えるというチームの状況だったので、それでペイできるという判断で未来への投資としてメンバーを説得しました」と回答。ちなみにPlaybookには「障害対応での思考の流れをドキュメント化する」という例を挙げた渡部ですが、これは作業中にSlackのスレに書き込んでいって、最後にまとめるそうです。 障害対応訓練に対して問われた渡部は、「簡単なものだと30分や1時間で障害環境を用意して、回答を受ける側も1時間程度で終わる」とのことで、極端に長時間化かかるような訓練はまだしていないということです。逆に言えば、それでも訓練としては意味があるということと言えそうです。 アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=JsfhvMffnHk