플러그인
플러그인 (Plugins)
플러그인은 제한된 클래스로더를 통해 코드를 엄격하게 분리할 수 있게 해줘요. 플러그인은 다른 플러그인이나 Flink의 다른 클래스 중에서 특별히 허용 목록에 있는 클래스에만 접근할 수 있어요. 이 엄격한 격리는 클래스를 리로케이트하거나 공통 버전으로 수렴할 필요 없이 플러그인이 같은 라이브러리의 충돌하는 버전을 담을 수 있게 해줘요. 현재는 파일 시스템과 메트릭 reporter가 플러그인 가능하지만, 앞으로는 커넥터, 포맷, 심지어 사용자 코드도 플러그인 가능해야 해요.
출처: 문서
본문
격리와 플러그인 구조 (Isolation and plugin structure)
플러그인은 자신의 폴더에 위치하며 여러 jar로 구성될 수 있어요. 플러그인 폴더의 이름은 임의로 정할 수 있어요.
flink-dist
├── conf
├── lib
...
└── plugins
├── s3
│ ├── aws-credential-provider.jar
│ └── flink-s3-fs-hadoop.jar
└── azure
└── flink-azure-fs-hadoop.jar
각 플러그인은 자신의 클래스로더를 통해 로드되며 다른 플러그인과 완전히 격리돼요. 따라서 flink-s3-fs-hadoop과 flink-azure-fs-hadoop은 서로 다른 충돌하는 라이브러리 버전에 의존할 수 있어요. fat jar 생성(shading) 중에 어떤 클래스도 리로케이트할 필요가 없어요.
플러그인은 Flink의 lib/ 폴더에 있는 특정 허용 목록 패키지에 접근할 수 있어요. 특히 필요한 모든 서비스 제공자 인터페이스(SPI)는 시스템 클래스로더를 통해 로드되므로, 사용자가 실수로 자기 fat jar에 포함시키더라도 org.apache.flink.core.fs.FileSystem의 두 버전이 동시에 존재하지 않아요. 이 단일 클래스 요구사항은 Flink 런타임이 플러그인으로 진입할 지점을 갖기 위해 반드시 필요해요. 서비스 클래스는 java.util.ServiceLoader를 통해 발견되므로 shading 중에 META-INF/services의 서비스 정의를 유지해야 해요.
참고: 현재 SPI 시스템을 구축하는 과정에서 더 많은 Flink 핵심 클래스가 여전히 플러그인에서 접근 가능해요.
또한 가장 일반적인 로거 프레임워크가 허용 목록에 있어서 Flink 코어, 플러그인, 사용자 코드에 걸쳐 로깅이 균일하게 가능해요.
파일 시스템 (File Systems)
모든 파일 시스템은 플러그인 가능해요. 즉 플러그인으로 사용할 수 있고 사용해야 해요. 플러그인 가능한 파일 시스템을 사용하려면 Flink를 시작하기 전에 해당 JAR 파일을 opt 디렉터리에서 Flink 배포의 plugins 디렉터리 아래 폴더로 복사해요:
mkdir ./plugins/s3-fs-hadoop
cp ./opt/flink-s3-fs-hadoop-2.3.0.jar ./plugins/s3-fs-hadoop/
s3 파일 시스템(flink-s3-fs-presto와 flink-s3-fs-hadoop)은 이미 리로케이션을 제거했으므로 플러그인으로만 사용할 수 있어요. libs/에 두면 시스템 장애가 발생해요.
엄격한 격리 때문에 파일 시스템은 더 이상 lib/의 자격 증명 제공자에 접근할 수 없어요. 필요한 제공자는 해당 플러그인 폴더에 추가해요.
메트릭 reporter (Metric Reporters)
Flink가 제공하는 모든 메트릭 reporter는 플러그인으로 사용할 수 있어요. 자세한 내용은 메트릭 문서를 참고해요.