SageMaker Studio架构

机器学习 (ML) 本质上是高度迭代和复杂的，需要数据科学家探索解决业务问题的多种方法。数据科学家必须使用支持交互式实验的工具，以便可以运行代码、检查其输出并对其进行注释，从而轻松地与其他团队成员合作。

SageMaker Studio 是一个完全集成的 ML 开发环境 (IDE)。它提供了一个基于 Web 的可视化界面，可以在其中执行构建、训练、调整、调试、部署和监控模型所需的所有 ML 开发步骤。它为数据科学家提供了将 ML 模型从实验转变为生产所需的所有工具，而无需离开 IDE。

Studio Notebook是可以快速启动的 Jupyter 笔记本。底层计算资源是完全弹性的，因此可以轻松地增加或减少可用资源，并且更改会在后台自动发生，而不会中断工作。还可以通过单击几下与其他人共享笔记本。他们得到完全相同的笔记本，并保存在同一个地方。

我们将仔细介绍Studio Notebook 是如何设计来提高数据科学家和开发人员的工作效率的。

单主机 Jupyter 架构

我们首先了解一下 Jupyter Notebook 是如何设置和访问的，Jupyter 笔记本默认托管在单台计算机上，可以通过任何 Web 浏览器访问。下图说明了在EC2上设置时它的工作原理。

img

通过打开浏览器并输入 Jupyter 服务器的 URL 来访问 Jupyter 笔记本，这会对托管 Jupyter 服务器的计算机进行 HTTPS/WSS 调用。该机器运行一个笔记本服务器，该服务器接收请求并使用Zeromq 与内核进程进行通信。

尽管这种架构很好地满足了数据科学家的需求，但一旦团队开始增长并且机器学习工作负载转移到生产环境，就会出现新的需求。这包括以下内容：

  • 每个数据科学家可能都在致力于自己的假设来解决机器学习问题，这需要安装自定义依赖项和包，而不影响其他人的工作。
  • 机器学习生命周期中的不同步骤可能需要不同的计算资源。例如，您可能需要大量内存来进行数据处理，但需要更多的 CPU 和 GPU 来进行训练。因此，扩展能力成为一个重要的要求。缺乏快速增加或减少资源的简单方法通常会导致资源配置不足或过度配置，从而进一步导致利用率低下和成本效率低下。
  • 为了克服这一问题，数据科学家可能经常更改 Jupyter 环境的实例类型，这进一步需要将工作区从一个实例移动到另一个实例，这会导致中断并降低工作效率。
  • 有时，Jupyter 环境可能不运行任何内核，仅用于读取示例笔记本或查看脚本和数据文件，但您仍然需要为用于渲染 Jupyter 环境的计算付费。需要将不同实例上的 UI 与内核计算解耦。
  • 对于大型团队来说，定期修补、保护和维护团队使用的所有数据科学环境开始成为一项开销。
  • 不同的团队成员可能正在处理相同的机器学习问题，但使用不同的方法来解决它。在这种情况下，团队成员之间轻松协作和共享工作就变得非常重要。通过版本控制系统 (VCS) 共享它并不是最佳选择，因为它缺乏对Notebook的良好支持。团队需要轻松协作和共享他们的工作和工件，而无需访问 VCS，同时还要保留状态。
  • 随着 ML 工作负载转移到生产环境，需要以自动化方式部署、监控和重新训练 ML 模型。这通常需要在不同工具之间切换，并且需要进行简化，以便从实验到生产的转变更加无缝，而无需在不同工具和服务之间切换。

SageMaker Studio架构

Studio 及其组件之一 Studio Notebook就是为了满足此类要求而构建的。Studio IDE 旨在统一 ML 开发所需的所有工具。开发人员可以在一个集成的可视化界面中编写代码、跟踪实验、可视化数据以及执行调试和监控，这显著提高了开发人员的工作效率。

img

Studio Notebook 的设计架构如下：

img

  1. Studio domain基于EFS 卷，并将安全、网络等相关的配置进行聚合。Domain促进用户之间的协作，他们可以与同一Domain中的其他用户共享笔记本和其他组件。

  2. 添加到 Studio Domain的每个用户都由一个用户配置文件(user profile)表示。此User Profile包含有关域中用户的唯一信息，例如用户的执行角色、EFS 卷中用户的Posix ID 等。

  3. SageMaker image引用 Docker 容器映像的元数据，存储在ECR中，通常包含 ML/DL框架库和运行内核所需的其他依赖项。

  4. Studio 附带了几个预构建的镜像(pre-build image) 。它还可以将自己的镜像附加到 Studio Domain，自定义镜像需要存储在 ECR 中。可以选择将自定义镜像附加到整个域或特定用户的User Profile配。有关更多信息，请参阅SageMaker 自定义映像示例 和将您自己的自定义容器映像引入 SageMaker Studio 笔记本 。

  5. App是为域中的用户运行的应用程序，以 Docker 容器的形式实现。Studio 目前支持两种类型的应用程序：

    • JupyterServer – JupyterServer app运行 Jupyter 服务器。每个用户都有一个在域内运行的独特且专用的 JupyterServer App。

    • KernelGateway – KernelGateway app对应于正在运行的 SageMaker容器。每个用户可以在单个 Studio 域中同时运行多个 KernelGateway app。

  6. 当用户使用 Web 浏览器访问 Studio UI 时，会与Notebook Server建立 HTTPS/WSS 连接，该服务器在 JupyterServer 容器内运行，而 JupyterServer 容器又在EC2 实例上运行。

Studio 使用 KernelGateway 架构允许Notebook server与远程主机上运行的内核进行通信；因此，Jupyter 内核不在Notebook Server所在的主机上运行，而是在单独主机上的 Docker 容器中运行。

每个用户只能运行一个给定类型（例如ml.t3.medium）的实例，每个实例上最多可以分配四个app；用户可以使用每个app生成多个笔记本和终端。如果需要在同一实例上运行四个以上应用程序，可以选择在不同类型的底层实例上运行。例如，可以选择在同一实例上运行 TensorFlow、PyTorch、MxNet、Data Science KernelGateway 应用程序，并分别运行多个笔记本；如果需要运行其他自定义应用程序，可以在不同的实例上启动它。

主机上运行的app之间不强制实施资源限制，因此每个app能够在给定时间占用所有计算资源。

每个app中可以运行多种内核类型，前提是所有内核在 CPU 或 GPU 上运行时具有相同的硬件要求。例如，除非在域或User Profile中进行了不同指定，否则 CPU 内核默认在 ml.t3.medium 上运行，GPU 内核在 ml.g4dn.xlarge 上运行，可以根据需要选择不同的计算资源。

如果Notebook需要更多计算和内存，还可以更改这些实例类型。在 Studio 中打开笔记本时，它会显示运行该笔记本的 EC2 实例（以黄色突出显示）的 vCPU 和内存：

img

可以选择不同的实例类型：

img

有些实例是快速启动类型，有些则不是。快速启动类型是将机器提前准备好了一个池子，以提供快速启动体验。

此外，如架构图所示，共享EFS 卷已安装到所有 KernelGateway 和 JupyterServer app。

访问Terminal

除了使用Notebook和在具有内核的Notebook中交互式运行代码之外，还可以与JupyterServer app(system terminal)和 KernelGateway app(image terminal)建立终端会话。前者在安装Notebook server扩展或运行文件系统操作时可能很有用, 后者用于在容器中安装特定库或从命令行运行脚本。

Image terminal

以下显示了在 KernelGateway app上运行的终端会话，以及在 ml.t3.medium 实例上运行的 Python3内核。

img

从截图中，我们可以看到已安装的 EFS 卷（以黄色突出显示）以及附加到容器的临时存储的EBS卷（以绿色突出显示）。我们可以看到，EFS 卷高达 8 EB，EBS 存储大小约为 83 GB，其中已使用约 11 GB。

System Terminal

以下截图显示了系统终端。同样，使用EFS 卷（以黄色突出显示）和 EBS 卷（以绿色突出显示）安装了不同的卷：

img

EFS 卷与image terminal上的卷相同。但是，此处的EFS 卷挂载点与 KernelGateway 容器的挂载点不同。此处，在总共 83 GB 的 EBS 卷大小中，已使用 9 GB。

存储

从存储角度来看，每个用户都可以在域下的EFS 卷上创建自己的私有主目录。对于每个用户，Studio 自动关联一个唯一的POSIX user/group ID (UID/GID)，以确保他们只能访问自己的目录。文件系统会自动安装到Notebook server容器和所有KernalGateway容器，如上一节所示。

Studio 的EFS 文件系统也可以由不同的客户端挂载：例如，可以将文件系统挂载到 EC2 实例并在主目录上运行漏洞扫描。以下显示了相关的API 调用，返回有关已安装的 EFS ID的详细信息：

img

使用相同的 EFS ID在 EC2 实例上挂载文件系统 。挂载成功后，我们还可以验证该卷的内容。以下显示了安装在 EC2 实例上的 Studio EFS 卷的内容：

img

Studio 还使用S3来存储Notebook快照和元数据以实现Notebook共享。除此之外，当在 Studio 中打开Notebook时， EBS 卷会附加到运行Notebook的实例。如果删除实例上运行的所有应用程序， EBS 卷将被删除。

可以使用KMS CMK加密 EFS 和 EBS 卷。有关详细信息，请参阅使用加密保护静态数据 。

联网

默认情况下，Studio 使用两个不同的 Virtual Private Cloud ( VPC)，其中一个 VPC 由 Studio 本身控制，并对公共互联网流量开放。另一个 VPC 由用户指定，并启用 Studio Domain和 EFS 卷之间的加密流量。有关更多详细信息，请参阅使用私有 VPC 保护 SageMaker Studio 连接 。

安全

Studio 使用run-as POSIX user/group来管理 JupyterServer app和 KernelGateWay app。JupyterServer app用户以sagemaker-user身份运行，具有 sudo 权限以启用 yum 软件包的安装，而 KernelGateway app用户以 root 身份运行，可以执行 pip/conda 安装，但都无法访问主机实例。除了默认run-as用户之外，容器内的用户还映射到Notebook实例上的非特权用户 ID 范围, 这是为了确保用户无法升级权限以超出容器并在 EC2 实例中执行任何受限操作。有关更多详细信息，请查看访问控制和 SageMaker Studio 笔记本 。

此外，SageMaker 添加了特定的路由规则来阻止从容器向 EFS 和IMDS发出请求，并且用户无法更改这些规则。Studio 中的所有网络间流量均经过 TLS 1.2 加密，禁止某些节点内流量，例如分布式训练或处理作业中的节点之间的通信以及服务控制平面与训练实例之间的通信。

定价

  • 使用 Studio Notebook时，需要支付计算和存储费用。

  • 存储费用：Notebook和相关项目（例如数据文件和脚本）将保留在 EFS 上。有关存储费用，请参阅EFS 定价。

  • 计算费用：在 Studio 域中，添加用户时，会为该用户启动 JupyterServer app，从而在浏览器中访问 Studio UI。此 JupyterServer app不向用户收费，仅针对底层 EFS 存储收费。用户可以继续使用 Studio UI 进行文件浏览、阅读Notebook以及访问 Studio 中的System terminal和其他 UI 组件，而不会产生任何计算成本。仅当用户选择用于Notebook的Kernel时，才会开始收取计算费用。

当用户关闭 EC2 实例上最后一个运行的 KernelGateway app时，该实例将自动关闭，并且 EC2 实例的计费将停止。因此，建议用户关闭任何未使用的 KernelGateway app，以避免产生意外费用。还可以使用Sagemaker-Studio-Autoshutdown 扩展自动关闭空闲内核**。**

使用 Studio Notebook的好处

  • Studio Notebook 为数据科学家和机器学习工程师提供了更简单的开发人员体验，从而提高了您的工作效率。
  • 将 Jupyter 服务器与内核解耦可以实现灵活性。底层计算资源是完全弹性的，因此您可以轻松地增加或减少可用资源，并且更改会在后台自动发生，而不会中断您的工作。
  • 使用 EFS 作为用户主目录的存储，从而将内核计算与存储分离，增加了额外的灵活性。由于EFS已挂载到客户的账户中，因此其他应用程序也仍然可以访问它。
  • Jupyter Server和KernalGateway的计算资源完全隔离并专用于每个用户。执行任何自定义安装都不会影响其他用户。
  • 协作变得更加容易，因为您只需单击几下即可与同一域中的其他用户共享Notebook
  • 企业级网络和安全控制已到位，因此用户无法在 Studio 中执行任何意外操作。
  • 该定价模型非常有效 - 只需要为运行Kernel的时间和EFS付费，但无需为 Jupyter server付费。
  • Docker 容器是 SageMaker 中的基础计算抽象。它们还用于运行处理、训练和推理。用户可以在 SageMaker 中对其 ML 环境进行 Docker 容器标准化，还可以灵活地将自己的 SageMaker 镜像引入 Studio。

总结：Studio Notebook 使用松散耦合的 KernelGateway 架构模式来实现可扩展性和灵活性，并为在同一Studio Domain中工作的每个用户提供强大的隔离功能，安全控制也到位，以避免用户发生任何意外操作。